Nabble - Grizzly - Users

Re: WebSocket status

2009-12-03T08:32:36Z

Hi Gustav,

first of all, thank you for the work you've done on websockets branch!
I'm really looking forward to see some websocket examples and blogs.

> Incoming dataframes concurrently trigger the websocketcontext
> listener onMessage method.
> The incoming rate vs the listener consumption rate is limited to a
> total number of bytes including datastructure overhead per socket,
> reads are throttled if a configured limit is passed (read interest
> is disabled, leaving throttling to TCP, and TCP is good at it.
> its one of the hardest things to get right when writing IO framework
> over UDP).
>
> Reads are performed in selector thread too, further reducing the
> context switches etc.

Are you using Grizzly selector threads or websocket infrastructure
reregisters websocket channels to own selector-threads?

> Selectorthread then finishes the writes, that is highly efficient
> due to there is no worker thread context switch per write,
> and the natural time lag at high load is causing writes to be more
> in bulk increasing overall efficiency further and there is
> significant less load on threadpool.
> Roundrobin load balancing among multiple selector threads is keeping
> the not directly writable IO work where it naturally belongs.
> The threadpool is not over used and can handle its remaining work
> better.
The same here. As I understand you use own websocket selector-threads
both for reads and writes?

> Multiple design decisions allow me to safely use my poison based
> fixed pool (recently patched in trunk to remove unnecessary atomic
> statistics) with and the now stable and highly improved LTQ.
> The 1.12 LTQ in grizzly that i prematurely pulled from doug cvs
> early this year is slow in comparison, just like sun perf team
> verified.
> It was still a win vs the CLQ for object caching. its another matter
> that both CLQ and LTQ now are vastly improved and whats optimal
> has changed.
I remember you mentioned some logic, which detects the current JDK
version and uses appropriate collection. Is it still the case?

> The threadpool is only one of several factors but it alone is
> interesting to compare.
> The performance and scalability is lowered by 2 to rather high 3
> digit percent numbers for when i use grizzly syncedpool for
> 3+ minute load tests each using 64 to 1024 sockets and DataFrame
> sizes from 2 to 16384 byte on a core i7.
IMO, it's not fair to compare those 2. SyncThreadPool is mostly used
for GF, because it supports min/max threads and more predictable in
its behavior. Otherwise nobody forces people to use SyncThreadPool.

> In grizzly 1.9 or 2.0 there is per design just too much _enforced_
> overhead in form of
> 1. too many context switches,
Can you pls. provide details, which switches we can avoid?

> 2. 1. are extra costly due the syncedpool design.
syncthreadpool is not design, it's implementation of a ThreadPool and
ExecutorService interface. Using the same interfaces (which are part
of design), you can build async implementation. So I'd say *design* is
not correct word here.

> the cost for load adapted pool size etc is _extreme_ when comparing
> to recently available alternatives like LTQ. but inorder to be able
> to take advantage of that , old ways to think must be abounded.
> That requires people that dont react with fear but instead become
> inspired...
LTQ is available since 1.6, Grizzly 1.9.x is JDK 1.5 compatible.
Personally I'm very inspired with the new LTQ, but in practice
customers will use JDK 1.5 for 5+ more years and will be happy.

> 3. overall design is indirectly leading to more channel read and
> writes then needed. very roughly 30K+ cycles overhead per call plus
> we risk to fragment tcp packets more then needed.
Can you pls. provide more details. Will appreciate your help in
improvment of those areas.

> When i want to talk about the possibility to allow services like
> websocket in grizzly 2.0 to not be enforced
> with low scaling high context switching design the answer is short,
> its not possible to make changes.
You make such a statement even without looking into 2.0, where for
each I/O operation you can chose whether you want to process it in the
same or worker thread.
Regarding changes... when you were told, that it's not possible to
make changes? If I remember correctly I was talking, that we're not
planning *big* *design* changes, but all reasonable improvment are
welcome.

> Well there is a general feeling of dead horse, no weekly project
> meetings anymore etc.
Agree, this should be changed. Having finished our work on GFv3, we
will have more time to work on Grizzly, so we will have info to share
on meetings.

> How are people supposed to work together in a team and still produce
> good stuff ?.
We still have mailing list, where trying to answer the question as
quickly as possible.

> I would gladly change my design or anything when i'm proved to be
> wrong or with sound technical reasoning convinced,
Ok.

> Me or anyone else ,cant as a single person try to drive the project
> and make it into something that would be competitive and only
> only "working".
I really appreciate the work you do!

Thanks.

WBR,
Alexey.

>
>
> --
> regards
> gustav trede
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

WebSocket status

2009-12-03T04:35:15Z

Hello,

I have experimented in websocket branch with free standing designs.
This to to see what performance and scalability i could attain while still keeping in/out data flows under control.
Simply by following the existing natural data flows and let data be transferred in bulk as side effect of overall efficient design, there is much to gain.
By very cheaply throttling, limiting queued IO per websocket in a configurable way the problems can be dealt with at appropriate level.

Incoming dataframes concurrently trigger the websocketcontext listener onMessage method.
The incoming rate vs the listener consumption rate is limited to a total number of bytes including datastructure overhead per socket, reads are throttled if a configured limit is passed (read interest is disabled, leaving throttling to TCP, and TCP is good at it.
its one of the hardest things to get right when writing IO framework over UDP).

Reads are performed in selector thread too, further reducing the context switches etc.

WebSocket.send allows DataFrame's to be sent concurrently.
When a websocketcontext listener representing a chat recieves onMessage event it can loop over the target sockets and send it
using the same DaFrame and same internal bytebuffer, data is never copied.
In all send calls data that is immediately writable is written, the rest sliced from dataframes internal bytebuffer and put on per socket queue.

Outstanding sends (data not reached socket native buffer) is limited too.
The websocket non formal spec docs recommends to close connection when limit is passed, so that is whats done for now.

To efficiently deal with real world data flows in an easy to easy way, websocketimpl send method does the following :
The amount of data to be sent is added to an per socket atomic integer.
if its value is > queue limit we close.
If value > 0 there is already queued send data.
if value is 0 there is no concurrent write, all data non native layers are flushed.

Its then safe to write to socket channel.
When the fist websocket.send has completed its channel.write and IF there is no buffered data in ssl etc,
By checkin the atomic integer it detect if there is any concurrent send call. if so grab that data from queue if is immiedetly avaialble and write it until queue or native socket stops.
If data still remains to write, register write interest.
Selectorthread then finishes the writes, that is highly efficient due to there is no worker thread context switch per write,
and the natural time lag at high load is causing writes to be more in bulk increasing overall efficiency further and there is significant less load on threadpool.
Roundrobin load balancing among multiple selector threads is keeping the not directly writable IO work where it naturally belongs.
The threadpool is not over used and can handle its remaining work better.

Multiple design decisions allow me to safely use my poison based fixed pool (recently patched in trunk to remove unnecessary atomic statistics) with and the now stable and highly improved LTQ.
The 1.12 LTQ in grizzly that i prematurely pulled from doug cvs early this year is slow in comparison, just like sun perf team verified.
It was still a win vs the CLQ for object caching. its another matter that both CLQ and LTQ now are vastly improved and whats optimal
has changed.

The threadpool is only one of several factors but it alone is interesting to compare.
The performance and scalability is lowered by 2 to rather high 3 digit percent numbers for when i use grizzly syncedpool for
3+ minute load tests each using 64 to 1024 sockets and DataFrame sizes from 2 to 16384 byte on a core i7.

When talking about glassfish integration and having to use whats available in grizzly, the various detrimental effects are not circumventable.
Because its not viable o have an entire extra io framework, doubling configuration needs and overall complexity.

In grizzly 1.9 or 2.0 there is per design just too much _enforced_ overhead in form of
1. too many context switches,
2. 1. are extra costly due the syncedpool design. the cost for load adapted pool size etc is _extreme_ when comparing to recently available alternatives like LTQ. but inorder to be able to take advantage of that , old ways to think must be abounded.
That requires people that dont react with fear but instead become inspired...
3. overall design is indirectly leading to more channel read and writes then needed. very roughly 30K+ cycles overhead per call plus we risk to fragment tcp packets more then needed.

I would happily integrate into 1.9 anyhow, just to let GF v3.x have websocket.

My thought was that things will be good in grizzly 2.0.
It would be nice if there would be different layers to hook up into,
so each service can get what it needs and nothing more.

When i want to talk about the possibility to allow services like websocket in grizzly 2.0 to not be enforced
with low scaling high context switching design the answer is short, its not possible to make changes.

The only argument is the projects inflated paper status, and no technical reason or discussion.
Well there is a general feeling of dead horse, no weekly project meetings anymore etc.
How are people supposed to work together in a team and still produce good stuff ?.

I would gladly change my design or anything when i'm proved to be wrong or with sound technical reasoning convinced,
then i would learn something and its a win win situation.

Me or anyone else ,cant as a single person try to drive the project and make it into something that would be competitive and only
only "working".
But when the current situation is what it is and there is lack of interest and resources to do what it takes to get a competitive product, its very hard for me to find motivation to integrate at all.
To me the reward "paycheck" for work is the feeling to have a done a good work,
that performs and scales not only well but as good as possible giving reasonable circumstances.

--
regards
gustav trede

NO PROJECT GRIZZLY MEETING December 2, 2009

2009-12-02T09:30:23Z

Hello,
there will be no grizzly meeting today.
Looks like we're mostly done with Glassfish V3 related work and
starting next week will come back to active work on Grizzly.

WBR,
Alexey.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

AW: AW: Multiple concurrent sendings vanish

2009-12-02T02:15:43Z

Alexey,
thanks again for the explanation!

That makes everything clear for me.

Grizzly is now going nicely!

By time, I'm trying to switch to 2.0

Cheers,
Kevin

> -----Ursprüngliche Nachricht-----
> Von: Oleksiy.Stashok@... [mailto:Oleksiy.Stashok@...]
> Gesendet: Mittwoch, 2. Dezember 2009 11:10
> An: users@...
> Betreff: Re: AW: Multiple concurrent sendings vanish
>
> Hi Kevin,
>
> >> If connection is being processed by a FilterChain (ProtocolParser
> >> etc), it shouldn't get timed out.
> > that is, what I exactly do (if you mean with FilterChain
> > ProtocolChain)!
> >
> > So my problem with closing connections should not appear?
> Right.
>
> > Sorry, now I'm really confused ;)
> Probably my explanations were not clear.
> Connection might be closed by timeout: when connection is idle longer
> than idle-timeout (no requests come), or connection request is waiting
> for a free worker thread longer than idle-timeout. Once we've got a
> worker thread to process the request - connection will *not* be timed
> out during worker thread processing.
>
> Having said that, want to mention, that we have different timeout
> setting for worker-thread processing, called transaction timeout,
> which will not let worker-thread to hang forever. But it's different
> story.
>
> Hope this will help.
>
> WBR,
> Alexey.
>
> >
> > Cheers,
> > Kevin
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: AW: Multiple concurrent sendings vanish

2009-12-02T02:10:29Z

Hi Kevin,

>> If connection is being processed by a FilterChain (ProtocolParser
>> etc), it shouldn't get timed out.
> that is, what I exactly do (if you mean with FilterChain
> ProtocolChain)!
>
> So my problem with closing connections should not appear?
Right.

> Sorry, now I'm really confused ;)
Probably my explanations were not clear.
Connection might be closed by timeout: when connection is idle longer
than idle-timeout (no requests come), or connection request is waiting
for a free worker thread longer than idle-timeout. Once we've got a
worker thread to process the request - connection will *not* be timed
out during worker thread processing.

Having said that, want to mention, that we have different timeout
setting for worker-thread processing, called transaction timeout,
which will not let worker-thread to hang forever. But it's different
story.

Hope this will help.

WBR,
Alexey.

>
> Cheers,
> Kevin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

AW: Multiple concurrent sendings vanish

2009-12-01T23:08:25Z

Hi Alexey,

> If connection is being processed by a FilterChain (ProtocolParser
> etc), it shouldn't get timed out.
that is, what I exactly do (if you mean with FilterChain ProtocolChain)!

So my problem with closing connections should not appear?

Sorry, now I'm really confused ;)

Cheers,
Kevin

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: exception when stress test

2009-12-01T02:04:40Z

Hi Ken,

can you pls. provide some testcase to reproduce this (may be privately)?

Thanks.

WBR,
Alexey.

On Dec 1, 2009, at 3:49 , Ken--@... wrote:

>
> Hi,
>
> We are performing stress test for our server (build on grizzly 2.0
> M3), we
> got the following exception when we increase the send rate to 16M
> bit/s:
>
> Any idea?
>
> Regards,
> Ken
>
>
> 2009年12月1日上午09:55:22 com.sun.grizzly.ProcessorRunnable
> logException
> 警告: Processor execution exception. Processor:
> com.sun.grizzly.nio.transport.TCPNIOAsyncQueueWriter@17e9fe8 Context:
> com.sun.grizzly.Context@4eefb4
> java.lang.IllegalArgumentException
> at java.nio.Buffer.position(Buffer.java:218)
> at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:291)
> at sun.nio.ch.IOUtil.write(IOUtil.java:70)
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:
> 334)
> at
> com
> .sun
> .grizzly.nio.transport.TCPNIOTransport.write(TCPNIOTransport.java:784)
> at
> com
> .sun
> .grizzly
> .nio
> .transport.TCPNIOAsyncQueueWriter.write0(TCPNIOAsyncQueueWriter.java:
> 89)
> at
> com
> .sun
> .grizzly
> .nio
> .AbstractNIOAsyncQueueWriter
> .doWrite(AbstractNIOAsyncQueueWriter.java:385)
> at
> com
> .sun
> .grizzly
> .nio
> .AbstractNIOAsyncQueueWriter
> .processAsync(AbstractNIOAsyncQueueWriter.java:256)
> at
> com
> .sun
> .grizzly
> .nio
> .AbstractNIOAsyncQueueWriter
> .process(AbstractNIOAsyncQueueWriter.java:354)
> at
> com.sun.grizzly.ProcessorRunnable.run(ProcessorRunnable.java:232)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:
> 441)
> at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor
> $Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor
> $Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> --
> View this message in context: http://old.nabble.com/exception-when-stress-test-tp26585715p26585715.html
> Sent from the Grizzly - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

exception when stress test

2009-11-30T18:49:30Z

Hi,

We are performing stress test for our server (build on grizzly 2.0 M3), we got the following exception when we increase the send rate to 16M bit/s:

Any idea?

Regards,
Ken

2009年12月1日上午09:55:22 com.sun.grizzly.ProcessorRunnable logException
警告: Processor execution exception. Processor: com.sun.grizzly.nio.transport.TCPNIOAsyncQueueWriter@17e9fe8 Context: com.sun.grizzly.Context@4eefb4
java.lang.IllegalArgumentException
at java.nio.Buffer.position(Buffer.java:218)
at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:291)
at sun.nio.ch.IOUtil.write(IOUtil.java:70)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334)
at com.sun.grizzly.nio.transport.TCPNIOTransport.write(TCPNIOTransport.java:784)
at com.sun.grizzly.nio.transport.TCPNIOAsyncQueueWriter.write0(TCPNIOAsyncQueueWriter.java:89)
at com.sun.grizzly.nio.AbstractNIOAsyncQueueWriter.doWrite(AbstractNIOAsyncQueueWriter.java:385)
at com.sun.grizzly.nio.AbstractNIOAsyncQueueWriter.processAsync(AbstractNIOAsyncQueueWriter.java:256)
at com.sun.grizzly.nio.AbstractNIOAsyncQueueWriter.process(AbstractNIOAsyncQueueWriter.java:354)
at com.sun.grizzly.ProcessorRunnable.run(ProcessorRunnable.java:232)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)

Re: confused with x mintues average connection queued count

2009-11-30T07:15:41Z

Hi,

good point.

This code is there for a long time, so may be this is just historical name/value mismatch. Can I ask you to file an issue for this?

Thank you.

WBR,

Alexey.

On Nov 27, 2009, at 1:07 , Ronghui Dai wrote:

Hi all,

The description of countqueued15minutesaverage-count is average number of connections queued in the last 15 minutes.

I thought the value should be sample several time in last 15 minutes get the connection-queue-count and calculate the average as the result, but the implementation of ThreadPoolStatistic.getCountQueued5MinuteAverage() and test result looks like it gets number of connection queued in last 15 minutes.

Did I miss something?
Cheers

Re: AW: AW: AW: AW: Multiple concurrent sendings vanish

2009-11-30T06:52:43Z

Hi Kevin

>> Jeanfrancois.Arcand:
>> If the client isn't sending anything for 30 seconds, the framework
>> close the connection.
> But in my case the client sent something, but no grizzly worker
> thread was ready to consume. So the framework marked those
> connection as closed (or closed them?)
It closes them.

> although there were bytes sent.
yes, but you can disable this behavior or increase timeout value.

> I just started to refactor my code to make those steps:
> 1) ProtocolParser parses the incoming bytes to a message
> 2) Submit this message to a threadpool
>

> I hope, this two steps are so fast, that the framework doesn't get a
> timeout for a connection.
If connection is being processed by a FilterChain (ProtocolParser
etc), it shouldn't get timed out.

> Is this a/the suggested way? Fast consuming of incoming bytes and
> delegating these bytes to a worker thread?
Protocol parser code gets called in worker thread, so, by default, you
shouldn't care about any delegation.
Only if you have some long lasting tasks (like SQL requests), it could
make sense to use additional custom thread-pool and process parsed
messages in this thread-pool, to not block worker threads.

WBR,
Alexey.

>> Usually ReadThreadCount == number of core/processor your machine
>> supports.
> Ah alright, so my setReadThreadCounts(5) doesn't make much
> sense... ;-)
>
> Thanks & cheers,
> Kevin
>
>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Oleksiy.Stashok@... [mailto:Oleksiy.Stashok@...]
>>>> Gesendet: Donnerstag, 19. November 2009 18:08
>>>> An: users@...
>>>> Betreff: Re: AW: AW: Multiple concurrent sendings vanish
>>>>
>>>> Hi Kevin,
>>>>
>>>> looks like you don't have any bugs in the code :)
>>>> Grizzly by default kills idle connections after 30 seconds timeout.
>> If
>>>> you're blocking threads for 7.5 seconds, it means that some
>> connection
>>>> requests could not be processed during > 30 seconds, these
>> connection
>>>> are getting closed... that's it.
>>>> To increase idle connection timeout to let's say 60 seconds - you
>> can
>>>> do this:
>>>>
>>>> private void configureServiceDispatcherHandler(
>>>> final int pServiceFileDownloadPort) {
>>>>
>>>> if (this.mSelectorHandler == null) {
>>>>
>>>> this.mSelectorHandler = new TCPSelectorHandler();
>>>>
>>>>
>>>> this.mSelectorHandler.setPort(pServiceFileDownloadPort);
>>>>
>>>> this.mSelectorHandler
>>>> .setProtocolChainInstanceHandler(new
>>>> DefaultProtocolChainInstanceHandler() {
>>>> @Override
>>>> public ProtocolChain poll() {
>>>> return
>>>> Server.this.mPROTOCOL_CHAIN;
>>>> }
>>>> });
>>>> +++ DefaultSelectionKeyHandler keyHandler =
>> new
>>>> DefaultSelectionKeyHandler();
>>>> +++ keyHandler.setTimeout(60000); // 60
>> seconds
>>>> timeout
>>>> +++
>>>> this.mSelectorHandler.setSelectionKeyHandler(keyHandler);
>>>>
>>>> }
>>>> }
>>>>
>>>> WBR,
>>>> Alexey.
>>>>
>>>>
>>>> On Nov 19, 2009, at 10:23 , Lohmann Kevin wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I attached code, that reproduces the problem.
>>>>>
>>>>> Meanwhile I guess, it has something to do with time... In the
>>>>> class
>>>>> 'ServerForwardFilter' in the method 'doSomeThingWithMessage' there
>>>>> is a sleep of 7.5 seconds. If I change these seconds to 5,
>>>>> everything works fine.
>>>>>
>>>>> Also I played with setting the ReadThreadsCount for the
>>>>> controller.
>>>>> Setting the counter high (up to 30), there are many threads (62),
>>>>> but this setting works fine for my problem.
>>>>>
>>>>> I'm pleased to get any remarks.
>>>>>
>>>>> Thanks & cheers,
>>>>> Kevin
>>>>>
>>>>>> -----Ursprüngliche Nachricht-----
>>>>>> Von: Oleksiy.Stashok@... [mailto:Oleksiy.Stashok@...]
>>>>>> Gesendet: Mittwoch, 18. November 2009 17:47
>>>>>> An: users@...
>>>>>> Betreff: Re: AW: Multiple concurrent sendings vanish
>>>>>>
>>>>>> Hi Kevin,
>>>>>>
>>>>>> can you pls. send server and client code, which reproduces the
>>>> issue.
>>>>>> Thank you.
>>>>>>
>>>>>> WBR,
>>>>>> Alexey.
>>>>>>
>>>>>> On Nov 18, 2009, at 13:42 , Lohmann Kevin wrote:
>>>>>>
>>>>>>> Sorry, one of the attached files was wrong, this one is the
>>>>>>> right
>>>>>> one.
>>>>>>> Cheers,
>>>>>>> Kevin
>>>>>>> <
>>>>>>> MyProtocolParser
>>>>>>> .java
>>>>>>>> ----------------------------------------------------------------
>> --
>>>> --
>>>>>> -
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>
>>>>>> ------------------------------------------------------------------
>> --
>>>> -
>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>> For additional commands, e-mail: users-help@...
>>>>> <
>>>>> code
>>>>> .zip
>>>>>> ------------------------------------------------------------------
>> --
>>>> -
>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>
>>>> --------------------------------------------------------------------
>> -
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Leaving Sun and Grizzly

2009-11-28T04:22:10Z

Your genius and enthusiasm will be sorely missed.

--
The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane. - Marcus Aurelius

Re: Leaving Sun and Grizzly

2009-11-26T18:06:22Z

Hi Jeanfrancois,

That's too sad news.

I always have appreciated your kindness.

And thank you for contributing much to the growth of the grizzly and glassfish.

But, as your words, I believe that the grizzly community is quite mature,

So I hope that the grizzly will continue to grow up.

Thanks.

--
Bongjae Chang

----- Original Message -----
From: "Jeanfrancois Arcand" <Jeanfrancois.Arcand@...>
To: <users@...>
Cc: <dev@...>
Sent: Wednesday, November 25, 2009 5:58 AM
Subject: Leaving Sun and Grizzly

> Salut,
>
> I promise this is the last email on the topic, but I just wanted to
> share this with the great community. On December 4, I will leave Sun:
>
> * http://is.gd/52NYd
>
> I would like to THANKS this community for the great support you give to
> Grizzly. Over more than 2 years I've enjoyed working in collaboration
> with all of you.
>
> Thanks for using Grizzly and Thanks for keeping this community active,
> independent and alive!
>
> -- Jeanfrancois
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

confused with x mintues average connection queued count

2009-11-26T16:07:52Z

Hi all,

The description of countqueued15minutesaverage-count is average number of connections queued in the last 15 minutes.

I thought the value should be sample several time in last 15 minutes get the connection-queue-count and calculate the average as the result, but the implementation of ThreadPoolStatistic.getCountQueued5MinuteAverage() and test result looks like it gets number of connection queued in last 15 minutes.

Did I miss something?

Cheers

Re: Leaving Sun and Grizzly

2009-11-26T12:49:04Z

Jeanfrancois Arcand:

Thank you for contributions on grizzly and your blog http://www.java.net/blogs/jfarcand/.

Ming Qin
Cell Phone 858-353-2839

--- On Tue, 11/24/09, Jeanfrancois Arcand <Jeanfrancois.Arcand@...> wrote:

From: Jeanfrancois Arcand <Jeanfrancois.Arcand@...>
Subject: Leaving Sun and Grizzly
To: users@...
Cc: dev@...
Date: Tuesday, November 24, 2009, 12:58 PM

Salut,

I promise this is the last email on the topic, but I just wanted to share this with the great community. On December 4, I will leave Sun:

* http://is.gd/52NYd

I would like to THANKS this community for the great support you give to Grizzly. Over more than 2 years I've enjoyed working in collaboration with all of you.

Thanks for using Grizzly and Thanks for keeping this community active, independent and alive!

-- Jeanfrancois

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: Response header order

2009-11-25T00:34:47Z

On Nov 24, 2009, at 9:19 PM, Jeanfrancois Arcand wrote:

> Salut,
>
> Paul Sandoz wrote:
>> Hi,
>> Anyone know if Grizzly (adapter and servlet) preserves the order of
>> headers that are added so that they occur on the wire in the same
>> order as they were added?
>
> Yes, it does. Do you see something different?

No. I just verified with curl and it is fine. Looks like
HttpURLConnection is not preserving the order at least when obtaining
the map of headers, so in-bound response logging using the Jersey
client shows headers out of order :-(

> Why do you need the exact order?
>

I am placing trace headers in the response e.g.:

< HTTP/1.1 200 OK
< server: grizzly/1.9.8
< X-Jersey-Trace-001: Root resource classes rule: /helloworld null
< X-Jersey-Trace-002: Right hand path rule: /helloworld null
< X-Jersey-Trace-003: Resource class rule: null
< X-Jersey-Trace-004: HTTP Method rule:
com.sun.jersey.samples.helloworld.resources.HelloWorldResource@ddbf6e
< Content-Type: text/plain
< Transfer-Encoding: chunked
< Date: Wed, 25 Nov 2009 08:19:17 GMT

So it is easier to debug the application if something has gone wrong
e.g. why the heck am i getting a 404 instead of a match on my resource
class?

The messages in the above need to be finessed.

I believe such information would be very useful in Atmosphere as well
even for broadcasting (the trace messages do not have to be placed in
the response but could be logged instead for such cases).

Paul.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Leaving Sun and Grizzly

2009-11-24T12:58:00Z

Salut,

I promise this is the last email on the topic, but I just wanted to
share this with the great community. On December 4, I will leave Sun:

* http://is.gd/52NYd

I would like to THANKS this community for the great support you give to
Grizzly. Over more than 2 years I've enjoyed working in collaboration
with all of you.

Thanks for using Grizzly and Thanks for keeping this community active,
independent and alive!

-- Jeanfrancois

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: grizzly 1.9.19-snapshot javadoc generated with UMLGraph.

2009-11-24T12:27:44Z

perfect. Will do a nice blog about that and commit it. Yes it will be useful.

Sébastien

2009/11/24 Jeanfrancois Arcand <Jeanfrancois.Arcand@...>

Survivant 00 wrote:

automatically generated when builded ?

You need to install Graphviz and add the path in the pom or used a variable like GRAPHVIZ_HOME (it's a default variable used by default)

if the folder is static in www/ I could do that upload the apidocs with uml unless it's overrided each time you do a release.

Yes we can update those file every release like we are doing for the javadoc. That would be quite helpful.

A+

--Jeanfrancois

2009/11/23 Jeanfrancois Arcand <Jeanfrancois.Arcand@... <mailto:Jeanfrancois.Arcand@...>>

Salut,

why not you commit the result under the www/ folder? I'm sure a lot
of peoples will be interested!!

A+

--Jeanfrancois

Survivant 00 wrote:

I generated javadoc for Grizzly with UMLGraph. Will give you
the UML within the javadoc. (PS I change the javadoc-plugin to
2.6.1 in my pom.xml, better support for aggregate javadoc)

you can download it if you want to check it out.

http://www.mediafire.com/file/enxdzdnmyfi/apidocs.rar

if you want to generate it your self it's really simple.

in the pom.xml

find this

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<configuration>
<aggregate>true</aggregate>
</configuration>
<executions>
<execution>
<id>attach-javadocs</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>

and

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.6.1</version>
<configuration>
<aggregate>true</aggregate>
<debug>true</debug>
<links>
<link>http://java.sun.com/javaee/5/docs/api</link>
<link>http://java.sun.com/j2se/1.5.0/docs/api</link>
</links>
<excludePackageNames>dojox:org.mortbay:com.sun.enterprise.web</excludePackageNames>
</configuration>
</plugin>

and change it for this :

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<configuration>
<aggregate>true</aggregate>
<doclet>org.umlgraph.doclet.UmlGraphDoc</doclet>
<docletArtifact>
<groupId>org.umlgraph</groupId>
<artifactId>doclet</artifactId>
<version>5.1</version>
</docletArtifact>
<additionalparam>-operations</additionalparam>
<additionalparam>-qualify</additionalparam>
<additionalparam>-types</additionalparam>
<additionalparam>-visibility</additionalparam>
<additionalparam>-collpackages</additionalparam>
<show>private</show>
</configuration>
<executions>
<execution>
<id>attach-javadocs</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>

the other block is

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.6.1</version>
<configuration>
<aggregate>true</aggregate>
<debug>true</debug>
<links>
<link>http://java.sun.com/javaee/5/docs/api</link>
<link>http://java.sun.com/j2se/1.5.0/docs/api</link>
</links>
<excludePackageNames>dojox:org.mortbay:com.sun.enterprise.web</excludePackageNames>
<doclet>org.umlgraph.doclet.UmlGraphDoc</doclet>
<docletArtifact>
<groupId>org.umlgraph</groupId>
<artifactId>doclet</artifactId>
<version>5.1</version>
</docletArtifact>
<additionalparam>-operations</additionalparam>
<additionalparam>-qualify</additionalparam>
<additionalparam>-types</additionalparam>
<additionalparam>-visibility</additionalparam>
<additionalparam>-collpackages</additionalparam>
<show>private</show>
</configuration>
</plugin>

--
Vous pouvez me suivre sur Twitter / You can follow me on Twitter
: http://twitter.com/survivant

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
<mailto:dev-unsubscribe@...>

For additional commands, e-mail: dev-help@...
<mailto:dev-help@...>

--

Vous pouvez me suivre sur Twitter / You can follow me on Twitter : http://twitter.com/survivant

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

--

Vous pouvez me suivre sur Twitter / You can follow me on Twitter : http://twitter.com/survivant

Re: grizzly 1.9.19-snapshot javadoc generated with UMLGraph.

2009-11-24T12:20:09Z

Survivant 00 wrote:
> automatically generated when builded ?
>
> You need to install Graphviz and add the path in the pom or used a
> variable like GRAPHVIZ_HOME (it's a default variable used by default)
>
>
> if the folder is static in www/ I could do that upload the apidocs with
> uml unless it's overrided each time you do a release.

Yes we can update those file every release like we are doing for the
javadoc. That would be quite helpful.

A+

--Jeanfrancois

>
> 2009/11/23 Jeanfrancois Arcand <Jeanfrancois.Arcand@...
> <mailto:Jeanfrancois.Arcand@...>>
>
> Salut,
>
> why not you commit the result under the www/ folder? I'm sure a lot
> of peoples will be interested!!
>
> A+
>
> --Jeanfrancois
>
>
> Survivant 00 wrote:
>
>
> I generated javadoc for Grizzly with UMLGraph. Will give you
> the UML within the javadoc. (PS I change the javadoc-plugin to
> 2.6.1 in my pom.xml, better support for aggregate javadoc)
>
>
> you can download it if you want to check it out.
>
> http://www.mediafire.com/file/enxdzdnmyfi/apidocs.rar
>
> if you want to generate it your self it's really simple.
>
>
> in the pom.xml
>
> find this
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-javadoc-plugin</artifactId>
> <configuration>
> <aggregate>true</aggregate>
> </configuration>
> <executions>
> <execution>
> <id>attach-javadocs</id>
> <goals>
> <goal>jar</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
>
> and
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-javadoc-plugin</artifactId>
> <version>2.6.1</version>
> <configuration>
> <aggregate>true</aggregate>
> <debug>true</debug>
> <links>
>
> <link>http://java.sun.com/javaee/5/docs/api</link>
>
> <link>http://java.sun.com/j2se/1.5.0/docs/api</link>
> </links>
>
> <excludePackageNames>dojox:org.mortbay:com.sun.enterprise.web</excludePackageNames>
> </configuration>
> </plugin>
>
> and change it for this :
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-javadoc-plugin</artifactId>
> <configuration>
> <aggregate>true</aggregate>
>
> <doclet>org.umlgraph.doclet.UmlGraphDoc</doclet>
> <docletArtifact>
>
> <groupId>org.umlgraph</groupId>
>
> <artifactId>doclet</artifactId>
>
> <version>5.1</version>
> </docletArtifact>
>
> <additionalparam>-operations</additionalparam>
>
> <additionalparam>-qualify</additionalparam>
>
> <additionalparam>-types</additionalparam>
>
> <additionalparam>-visibility</additionalparam>
>
> <additionalparam>-collpackages</additionalparam>
>
> <show>private</show>
> </configuration>
> <executions>
> <execution>
> <id>attach-javadocs</id>
> <goals>
> <goal>jar</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
>
> the other block is
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-javadoc-plugin</artifactId>
> <version>2.6.1</version>
> <configuration>
> <aggregate>true</aggregate>
> <debug>true</debug>
> <links>
>
> <link>http://java.sun.com/javaee/5/docs/api</link>
>
> <link>http://java.sun.com/j2se/1.5.0/docs/api</link>
> </links>
>
> <excludePackageNames>dojox:org.mortbay:com.sun.enterprise.web</excludePackageNames>
> <doclet>org.umlgraph.doclet.UmlGraphDoc</doclet>
> <docletArtifact>
> <groupId>org.umlgraph</groupId>
> <artifactId>doclet</artifactId>
> <version>5.1</version>
> </docletArtifact>
> <additionalparam>-operations</additionalparam>
> <additionalparam>-qualify</additionalparam>
> <additionalparam>-types</additionalparam>
> <additionalparam>-visibility</additionalparam>
> <additionalparam>-collpackages</additionalparam>
> <show>private</show>
> </configuration>
> </plugin>
>
> --
>
> Vous pouvez me suivre sur Twitter / You can follow me on Twitter
> : http://twitter.com/survivant
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> <mailto:dev-unsubscribe@...>
> For additional commands, e-mail: dev-help@...
> <mailto:dev-help@...>
>
>
>
>
> --
>
> Vous pouvez me suivre sur Twitter / You can follow me on Twitter :
> http://twitter.com/survivant

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Response header order

2009-11-24T12:19:19Z

Salut,

Paul Sandoz wrote:
> Hi,
>
> Anyone know if Grizzly (adapter and servlet) preserves the order of
> headers that are added so that they occur on the wire in the same order
> as they were added?

Yes, it does. Do you see something different? Why do you need the exact
order?

A+

-- Jeanfrancois

>
> Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Response header order

2009-11-24T08:43:35Z

Hi,

Anyone know if Grizzly (adapter and servlet) preserves the order of
headers that are added so that they occur on the wire in the same
order as they were added?

Paul.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: grizzly 1.9.19-snapshot javadoc generated with UMLGraph.

2009-11-24T03:46:39Z

automatically generated when builded ?

You need to install Graphviz and add the path in the pom or used a variable like GRAPHVIZ_HOME (it's a default variable used by default)

if the folder is static in www/ I could do that upload the apidocs with uml unless it's overrided each time you do a release.

2009/11/23 Jeanfrancois Arcand <Jeanfrancois.Arcand@...>

Salut,

why not you commit the result under the www/ folder? I'm sure a lot of peoples will be interested!!

A+

--Jeanfrancois

Survivant 00 wrote:

I generated javadoc for Grizzly with UMLGraph. Will give you the UML within the javadoc. (PS I change the javadoc-plugin to 2.6.1 in my pom.xml, better support for aggregate javadoc)

you can download it if you want to check it out.

http://www.mediafire.com/file/enxdzdnmyfi/apidocs.rar

if you want to generate it your self it's really simple.

in the pom.xml

find this

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<configuration>
<aggregate>true</aggregate>
</configuration>
<executions>
<execution>
<id>attach-javadocs</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>

and

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.6.1</version>
<configuration>
<aggregate>true</aggregate>
<debug>true</debug>
<links>
<link>http://java.sun.com/javaee/5/docs/api</link>
<link>http://java.sun.com/j2se/1.5.0/docs/api</link>
</links>
<excludePackageNames>dojox:org.mortbay:com.sun.enterprise.web</excludePackageNames>
</configuration>
</plugin>

and change it for this :

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<configuration>
<aggregate>true</aggregate>
<doclet>org.umlgraph.doclet.UmlGraphDoc</doclet>
<docletArtifact>
<groupId>org.umlgraph</groupId>
<artifactId>doclet</artifactId>
<version>5.1</version>
</docletArtifact>
<additionalparam>-operations</additionalparam>
<additionalparam>-qualify</additionalparam>
<additionalparam>-types</additionalparam>
<additionalparam>-visibility</additionalparam>
<additionalparam>-collpackages</additionalparam>
<show>private</show>
</configuration>
<executions>
<execution>
<id>attach-javadocs</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>

the other block is

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.6.1</version>
<configuration>
<aggregate>true</aggregate>
<debug>true</debug>
<links>
<link>http://java.sun.com/javaee/5/docs/api</link>
<link>http://java.sun.com/j2se/1.5.0/docs/api</link>
</links>
<excludePackageNames>dojox:org.mortbay:com.sun.enterprise.web</excludePackageNames>
<doclet>org.umlgraph.doclet.UmlGraphDoc</doclet>
<docletArtifact>
<groupId>org.umlgraph</groupId>
<artifactId>doclet</artifactId>
<version>5.1</version>
</docletArtifact>
<additionalparam>-operations</additionalparam>
<additionalparam>-qualify</additionalparam>
<additionalparam>-types</additionalparam>
<additionalparam>-visibility</additionalparam>
<additionalparam>-collpackages</additionalparam>
<show>private</show>
</configuration>
</plugin>

--

Vous pouvez me suivre sur Twitter / You can follow me on Twitter : http://twitter.com/survivant

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

--

Vous pouvez me suivre sur Twitter / You can follow me on Twitter : http://twitter.com/survivant

AW: AW: AW: AW: Multiple concurrent sendings vanish

2009-11-23T23:09:35Z

Hi Jeanfrancois,

thanks for stepping in :)

> Jeanfrancois.Arcand:
> If the client isn't sending anything for 30 seconds, the framework
> close the connection.
But in my case the client sent something, but no grizzly worker thread was ready to consume. So the framework marked those connection as closed (or closed them?) although there were bytes sent.

I just started to refactor my code to make those steps:
1) ProtocolParser parses the incoming bytes to a message
2) Submit this message to a threadpool

I hope, this two steps are so fast, that the framework doesn't get a timeout for a connection.

Is this a/the suggested way? Fast consuming of incoming bytes and delegating these bytes to a worker thread?

> Usually ReadThreadCount == number of core/processor your machine
> supports.
Ah alright, so my setReadThreadCounts(5) doesn't make much sense... ;-)

Thanks & cheers,
Kevin

> >> -----Ursprüngliche Nachricht-----
> >> Von: Oleksiy.Stashok@... [mailto:Oleksiy.Stashok@...]
> >> Gesendet: Donnerstag, 19. November 2009 18:08
> >> An: users@...
> >> Betreff: Re: AW: AW: Multiple concurrent sendings vanish
> >>
> >> Hi Kevin,
> >>
> >> looks like you don't have any bugs in the code :)
> >> Grizzly by default kills idle connections after 30 seconds timeout.
> If
> >> you're blocking threads for 7.5 seconds, it means that some
> connection
> >> requests could not be processed during > 30 seconds, these
> connection
> >> are getting closed... that's it.
> >> To increase idle connection timeout to let's say 60 seconds - you
> can
> >> do this:
> >>
> >> private void configureServiceDispatcherHandler(
> >> final int pServiceFileDownloadPort) {
> >>
> >> if (this.mSelectorHandler == null) {
> >>
> >> this.mSelectorHandler = new TCPSelectorHandler();
> >>
> >>
> >> this.mSelectorHandler.setPort(pServiceFileDownloadPort);
> >>
> >> this.mSelectorHandler
> >> .setProtocolChainInstanceHandler(new
> >> DefaultProtocolChainInstanceHandler() {
> >> @Override
> >> public ProtocolChain poll() {
> >> return
> >> Server.this.mPROTOCOL_CHAIN;
> >> }
> >> });
> >> +++ DefaultSelectionKeyHandler keyHandler =
> new
> >> DefaultSelectionKeyHandler();
> >> +++ keyHandler.setTimeout(60000); // 60
> seconds
> >> timeout
> >> +++
> >> this.mSelectorHandler.setSelectionKeyHandler(keyHandler);
> >>
> >> }
> >> }
> >>
> >> WBR,
> >> Alexey.
> >>
> >>
> >> On Nov 19, 2009, at 10:23 , Lohmann Kevin wrote:
> >>
> >>> Hi,
> >>>
> >>> I attached code, that reproduces the problem.
> >>>
> >>> Meanwhile I guess, it has something to do with time... In the class
> >>> 'ServerForwardFilter' in the method 'doSomeThingWithMessage' there
> >>> is a sleep of 7.5 seconds. If I change these seconds to 5,
> >>> everything works fine.
> >>>
> >>> Also I played with setting the ReadThreadsCount for the controller.
> >>> Setting the counter high (up to 30), there are many threads (62),
> >>> but this setting works fine for my problem.
> >>>
> >>> I'm pleased to get any remarks.
> >>>
> >>> Thanks & cheers,
> >>> Kevin
> >>>
> >>>> -----Ursprüngliche Nachricht-----
> >>>> Von: Oleksiy.Stashok@... [mailto:Oleksiy.Stashok@...]
> >>>> Gesendet: Mittwoch, 18. November 2009 17:47
> >>>> An: users@...
> >>>> Betreff: Re: AW: Multiple concurrent sendings vanish
> >>>>
> >>>> Hi Kevin,
> >>>>
> >>>> can you pls. send server and client code, which reproduces the
> >> issue.
> >>>> Thank you.
> >>>>
> >>>> WBR,
> >>>> Alexey.
> >>>>
> >>>> On Nov 18, 2009, at 13:42 , Lohmann Kevin wrote:
> >>>>
> >>>>> Sorry, one of the attached files was wrong, this one is the right
> >>>> one.
> >>>>> Cheers,
> >>>>> Kevin
> >>>>> <
> >>>>> MyProtocolParser
> >>>>> .java
> >>>>>> ----------------------------------------------------------------
> --
> >> --
> >>>> -
> >>>>> To unsubscribe, e-mail: users-unsubscribe@...
> >>>>> For additional commands, e-mail: users-help@...
> >>>>
> >>>> ------------------------------------------------------------------
> --
> >> -
> >>>> To unsubscribe, e-mail: users-unsubscribe@...
> >>>> For additional commands, e-mail: users-help@...
> >>> <
> >>> code
> >>> .zip
> >>>> ------------------------------------------------------------------
> --
> >> -
> >>> To unsubscribe, e-mail: users-unsubscribe@...
> >>> For additional commands, e-mail: users-help@...
> >>
> >> --------------------------------------------------------------------
> -
> >> To unsubscribe, e-mail: users-unsubscribe@...
> >> For additional commands, e-mail: users-help@...
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: AW: AW: AW: Multiple concurrent sendings vanish

2009-11-23T18:51:05Z

Salut,

Lohmann Kevin wrote:
> Hi Alexey,
>
> thanks for the explanation, it works now.
>
> But is it up to me to decide, how long the timeout could last? The client sent its request and just because none of the grizzly threads reacts, the request is marked as idle?

If the client isn't sending anything for 30 seconds, the framework close
the connection.

>
> Has anyone experiences in setting the timeout up? What is a good timeout in terms of performance etc.?

It really depend on the behavior you want to have, e.g do you wnat to
allow idle connection?

>
> What about the ReadThreadsCount? Would combining setting this count and timeout be a better solution?

Usually ReadThreadCount == number of core/processor your machine supports.

A+

-- jeanfrancois

>
> Thanks & cheers,
> Kevin
>
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Oleksiy.Stashok@... [mailto:Oleksiy.Stashok@...]
>> Gesendet: Donnerstag, 19. November 2009 18:08
>> An: users@...
>> Betreff: Re: AW: AW: Multiple concurrent sendings vanish
>>
>> Hi Kevin,
>>
>> looks like you don't have any bugs in the code :)
>> Grizzly by default kills idle connections after 30 seconds timeout. If
>> you're blocking threads for 7.5 seconds, it means that some connection
>> requests could not be processed during > 30 seconds, these connection
>> are getting closed... that's it.
>> To increase idle connection timeout to let's say 60 seconds - you can
>> do this:
>>
>> private void configureServiceDispatcherHandler(
>> final int pServiceFileDownloadPort) {
>>
>> if (this.mSelectorHandler == null) {
>>
>> this.mSelectorHandler = new TCPSelectorHandler();
>>
>>
>> this.mSelectorHandler.setPort(pServiceFileDownloadPort);
>>
>> this.mSelectorHandler
>> .setProtocolChainInstanceHandler(new
>> DefaultProtocolChainInstanceHandler() {
>> @Override
>> public ProtocolChain poll() {
>> return
>> Server.this.mPROTOCOL_CHAIN;
>> }
>> });
>> +++ DefaultSelectionKeyHandler keyHandler = new
>> DefaultSelectionKeyHandler();
>> +++ keyHandler.setTimeout(60000); // 60 seconds
>> timeout
>> +++
>> this.mSelectorHandler.setSelectionKeyHandler(keyHandler);
>>
>> }
>> }
>>
>> WBR,
>> Alexey.
>>
>>
>> On Nov 19, 2009, at 10:23 , Lohmann Kevin wrote:
>>
>>> Hi,
>>>
>>> I attached code, that reproduces the problem.
>>>
>>> Meanwhile I guess, it has something to do with time... In the class
>>> 'ServerForwardFilter' in the method 'doSomeThingWithMessage' there
>>> is a sleep of 7.5 seconds. If I change these seconds to 5,
>>> everything works fine.
>>>
>>> Also I played with setting the ReadThreadsCount for the controller.
>>> Setting the counter high (up to 30), there are many threads (62),
>>> but this setting works fine for my problem.
>>>
>>> I'm pleased to get any remarks.
>>>
>>> Thanks & cheers,
>>> Kevin
>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Oleksiy.Stashok@... [mailto:Oleksiy.Stashok@...]
>>>> Gesendet: Mittwoch, 18. November 2009 17:47
>>>> An: users@...
>>>> Betreff: Re: AW: Multiple concurrent sendings vanish
>>>>
>>>> Hi Kevin,
>>>>
>>>> can you pls. send server and client code, which reproduces the
>> issue.
>>>> Thank you.
>>>>
>>>> WBR,
>>>> Alexey.
>>>>
>>>> On Nov 18, 2009, at 13:42 , Lohmann Kevin wrote:
>>>>
>>>>> Sorry, one of the attached files was wrong, this one is the right
>>>> one.
>>>>> Cheers,
>>>>> Kevin
>>>>> <
>>>>> MyProtocolParser
>>>>> .java
>>>>>> ------------------------------------------------------------------
>> --
>>>> -
>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>
>>>> --------------------------------------------------------------------
>> -
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>> <
>>> code
>>> .zip
>>>> --------------------------------------------------------------------
>> -
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: grizzly 1.9.19-snapshot javadoc generated with UMLGraph.

2009-11-23T18:49:13Z

Salut,

why not you commit the result under the www/ folder? I'm sure a lot of
peoples will be interested!!

A+

--Jeanfrancois

Survivant 00 wrote:

>
> I generated javadoc for Grizzly with UMLGraph. Will give you the UML
> within the javadoc. (PS I change the javadoc-plugin to 2.6.1 in my
> pom.xml, better support for aggregate javadoc)
>
>
> you can download it if you want to check it out.
>
> http://www.mediafire.com/file/enxdzdnmyfi/apidocs.rar
>
>
> if you want to generate it your self it's really simple.
>
>
> in the pom.xml
>
> find this
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-javadoc-plugin</artifactId>
> <configuration>
> <aggregate>true</aggregate>
> </configuration>
> <executions>
> <execution>
> <id>attach-javadocs</id>
> <goals>
> <goal>jar</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
>
> and
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-javadoc-plugin</artifactId>
> <version>2.6.1</version>
> <configuration>
> <aggregate>true</aggregate>
> <debug>true</debug>
> <links>
> <link>http://java.sun.com/javaee/5/docs/api</link>
> <link>http://java.sun.com/j2se/1.5.0/docs/api</link>
> </links>
>
> <excludePackageNames>dojox:org.mortbay:com.sun.enterprise.web</excludePackageNames>
> </configuration>
> </plugin>
>
> and change it for this :
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-javadoc-plugin</artifactId>
> <configuration>
> <aggregate>true</aggregate>
> <doclet>org.umlgraph.doclet.UmlGraphDoc</doclet>
> <docletArtifact>
>
> <groupId>org.umlgraph</groupId>
>
> <artifactId>doclet</artifactId>
> <version>5.1</version>
> </docletArtifact>
>
> <additionalparam>-operations</additionalparam>
>
> <additionalparam>-qualify</additionalparam>
>
> <additionalparam>-types</additionalparam>
>
> <additionalparam>-visibility</additionalparam>
>
> <additionalparam>-collpackages</additionalparam>
>
> <show>private</show>
> </configuration>
> <executions>
> <execution>
> <id>attach-javadocs</id>
> <goals>
> <goal>jar</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
>
> the other block is
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-javadoc-plugin</artifactId>
> <version>2.6.1</version>
> <configuration>
> <aggregate>true</aggregate>
> <debug>true</debug>
> <links>
> <link>http://java.sun.com/javaee/5/docs/api</link>
> <link>http://java.sun.com/j2se/1.5.0/docs/api</link>
> </links>
>
> <excludePackageNames>dojox:org.mortbay:com.sun.enterprise.web</excludePackageNames>
> <doclet>org.umlgraph.doclet.UmlGraphDoc</doclet>
> <docletArtifact>
> <groupId>org.umlgraph</groupId>
> <artifactId>doclet</artifactId>
> <version>5.1</version>
> </docletArtifact>
> <additionalparam>-operations</additionalparam>
> <additionalparam>-qualify</additionalparam>
> <additionalparam>-types</additionalparam>
> <additionalparam>-visibility</additionalparam>
> <additionalparam>-collpackages</additionalparam>
>
> <show>private</show>
> </configuration>
> </plugin>
>
> --
>
> Vous pouvez me suivre sur Twitter / You can follow me on Twitter :
> http://twitter.com/survivant

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: GrizzlyWebServerDeployer -- Error could not deploy WAR correctly

2009-11-23T17:54:19Z

I didn't forget you... I'm tracing into Spring now.. Still don't know why Spring throw an Exception.

To simplify the test, I unpack the war file into a folder and run from it.. but I still got this exception :

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'authenticationManager' defined in ServletContext resource [/WEB-INF/deployerConfigContext.xml]: Cannot create inner bean 'org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler#3f5ae2' of type [org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler] while setting bean property 'authenticationHandlers' with key [0]; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler#3f5ae2' defined in ServletContext resource [/WEB-INF/deployerConfigContext.xml]: Cannot resolve reference to bean 'httpClient' while setting bean property 'httpClient'; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'httpClient' is defined
authenticationManager
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler#3f5ae2' defined in ServletContext resource [/WEB-INF/deployerConfigContext.xml]: Cannot resolve reference to bean 'httpClient' while setting bean property 'httpClient'; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'httpClient' is defined
Error creating bean with name 'authenticationManager' defined in ServletContext resource [/WEB-INF/deployerConfigContext.xml]: Cannot create inner bean 'org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler#3f5ae2' of type [org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler] while setting bean property 'authenticationHandlers' with key [0]

Will give you feedback this week.. working on that every night for this week.

2009/11/16 Shawn Pan <xpan@...>

Among all the things I like about Grizzly, a big one is that it has a much, much smaller footprint comparing to Glassfish... yes, you are correct, I can use Glassfish as my backup :)

Survivant 00 wrote:

:)

you could do the demo using Glassfish in the last resort.. it's build over Grizzly :)

2009/11/16 Shawn Pan <xpan@... <mailto:xpan@...>>

Thanks whole bunch!

My company will soon have an internal review on a project that I am
working on, and I would like to convince them to use Grizzly for many
good reasons. It would be nice if this deployer bug can be fix by
then.

Shawn

On Mon, Nov 16, 2009 at 2:42 PM, Survivant 00
<survivant00@... <mailto:survivant00@...>> wrote:
> Hubert release a internal patch, but it doesn't work on Windows
with CAS.
> I'll pop him tonight ask if he did some progress.
>
> for my part.. I'll start a blog about WarAdapter with example.
>
>
> 2009/11/16 Shawn Pan <xpan@... <mailto:xpan@...>>

>>
>> Hey survivant, any progress on the fix?
>>
>> On Tue, Nov 10, 2009 at 4:34 PM, Survivant 00
<survivant00@... <mailto:survivant00@...>>

>> wrote:
>> > ok, I'll have to test them in debug.
>> >
>> > it sure that Grizzly have to support them. That was what I
had in mind
>> > want
>> > I created Deployer.
>> >
>> > We started a embedded version for Deployer, but we broke it,
and now
>> > I'll
>> > have to fix it, because the others are busy.
>> >
>> > I have tested lot of war with Deployer, but theses two are
differents.
>> > Look
>> > like I forgot to do a "if" somewhere.. Shouldn'T be to hard
to find now
>> > that
>> > I have sample that doesn't work.
>
>
>
> --
>
> Vous pouvez me suivre sur Twitter / You can follow me on Twitter :
> http://twitter.com/survivant
>

--

Vous pouvez me suivre sur Twitter / You can follow me on Twitter : http://twitter.com/survivant

--

Vous pouvez me suivre sur Twitter / You can follow me on Twitter : http://twitter.com/survivant

grizzly 1.9.19-snapshot javadoc generated with UMLGraph.

2009-11-20T06:05:38Z

I generated javadoc for Grizzly with UMLGraph. Will give you the UML within the javadoc. (PS I change the javadoc-plugin to 2.6.1 in my pom.xml, better support for aggregate javadoc)

you can download it if you want to check it out.

http://www.mediafire.com/file/enxdzdnmyfi/apidocs.rar

if you want to generate it your self it's really simple.

in the pom.xml

find this

<plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-javadoc-plugin</artifactId>
                        <configuration>
                            <aggregate>true</aggregate>
                        </configuration>
                        <executions>
                            <execution>
                                <id>attach-javadocs</id>
                                <goals>
                                    <goal>jar</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>

and

<plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-javadoc-plugin</artifactId>
                <version>2.6.1</version>
                <configuration>
                    <aggregate>true</aggregate>
                    <debug>true</debug>
                    <links>
                        <link>http://java.sun.com/javaee/5/docs/api</link>
                        <link>http://java.sun.com/j2se/1.5.0/docs/api</link>
                    </links>
                    <excludePackageNames>dojox:org.mortbay:com.sun.enterprise.web</excludePackageNames>
                </configuration>
            </plugin>

and change it for this :

<plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-javadoc-plugin</artifactId>
                        <configuration>
                            <aggregate>true</aggregate>
                            <doclet>org.umlgraph.doclet.UmlGraphDoc</doclet>
                                              <docletArtifact>
                                                <groupId>org.umlgraph</groupId>
                                                <artifactId>doclet</artifactId>
                                                <version>5.1</version>
                                              </docletArtifact>
                                              <additionalparam>-operations</additionalparam>
                                        <additionalparam>-qualify</additionalparam>
                                        <additionalparam>-types</additionalparam>
                                        <additionalparam>-visibility</additionalparam>
                                        <additionalparam>-collpackages</additionalparam>

                                        <show>private</show>
                        </configuration>
                        <executions>
                            <execution>
                                <id>attach-javadocs</id>
                                <goals>
                                    <goal>jar</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>

the other block is

<plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-javadoc-plugin</artifactId>
                <version>2.6.1</version>
                <configuration>
                    <aggregate>true</aggregate>
                    <debug>true</debug>
                    <links>
                        <link>http://java.sun.com/javaee/5/docs/api</link>
                        <link>http://java.sun.com/j2se/1.5.0/docs/api</link>
                    </links>
                    <excludePackageNames>dojox:org.mortbay:com.sun.enterprise.web</excludePackageNames>
                    <doclet>org.umlgraph.doclet.UmlGraphDoc</doclet>
                      <docletArtifact>
                        <groupId>org.umlgraph</groupId>
                        <artifactId>doclet</artifactId>
                        <version>5.1</version>
                      </docletArtifact>
                      <additionalparam>-operations</additionalparam>
                <additionalparam>-qualify</additionalparam>
                <additionalparam>-types</additionalparam>
                <additionalparam>-visibility</additionalparam>
                <additionalparam>-collpackages</additionalparam>

                <show>private</show>
                </configuration>
            </plugin>

--

Vous pouvez me suivre sur Twitter / You can follow me on Twitter : http://twitter.com/survivant

AW: AW: AW: Multiple concurrent sendings vanish

2009-11-20T01:20:49Z

Hi Alexey,

thanks for the explanation, it works now.

But is it up to me to decide, how long the timeout could last? The client sent its request and just because none of the grizzly threads reacts, the request is marked as idle?

Has anyone experiences in setting the timeout up? What is a good timeout in terms of performance etc.?

What about the ReadThreadsCount? Would combining setting this count and timeout be a better solution?

Thanks & cheers,
Kevin

> -----Ursprüngliche Nachricht-----
> Von: Oleksiy.Stashok@... [mailto:Oleksiy.Stashok@...]
> Gesendet: Donnerstag, 19. November 2009 18:08
> An: users@...
> Betreff: Re: AW: AW: Multiple concurrent sendings vanish
>
> Hi Kevin,
>
> looks like you don't have any bugs in the code :)
> Grizzly by default kills idle connections after 30 seconds timeout. If
> you're blocking threads for 7.5 seconds, it means that some connection
> requests could not be processed during > 30 seconds, these connection
> are getting closed... that's it.
> To increase idle connection timeout to let's say 60 seconds - you can
> do this:
>
> private void configureServiceDispatcherHandler(
> final int pServiceFileDownloadPort) {
>
> if (this.mSelectorHandler == null) {
>
> this.mSelectorHandler = new TCPSelectorHandler();
>
>
> this.mSelectorHandler.setPort(pServiceFileDownloadPort);
>
> this.mSelectorHandler
> .setProtocolChainInstanceHandler(new
> DefaultProtocolChainInstanceHandler() {
> @Override
> public ProtocolChain poll() {
> return
> Server.this.mPROTOCOL_CHAIN;
> }
> });
> +++ DefaultSelectionKeyHandler keyHandler = new
> DefaultSelectionKeyHandler();
> +++ keyHandler.setTimeout(60000); // 60 seconds
> timeout
> +++
> this.mSelectorHandler.setSelectionKeyHandler(keyHandler);
>
> }
> }
>
> WBR,
> Alexey.
>
>
> On Nov 19, 2009, at 10:23 , Lohmann Kevin wrote:
>
> > Hi,
> >
> > I attached code, that reproduces the problem.
> >
> > Meanwhile I guess, it has something to do with time... In the class
> > 'ServerForwardFilter' in the method 'doSomeThingWithMessage' there
> > is a sleep of 7.5 seconds. If I change these seconds to 5,
> > everything works fine.
> >
> > Also I played with setting the ReadThreadsCount for the controller.
> > Setting the counter high (up to 30), there are many threads (62),
> > but this setting works fine for my problem.
> >
> > I'm pleased to get any remarks.
> >
> > Thanks & cheers,
> > Kevin
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von: Oleksiy.Stashok@... [mailto:Oleksiy.Stashok@...]
> >> Gesendet: Mittwoch, 18. November 2009 17:47
> >> An: users@...
> >> Betreff: Re: AW: Multiple concurrent sendings vanish
> >>
> >> Hi Kevin,
> >>
> >> can you pls. send server and client code, which reproduces the
> issue.
> >>
> >> Thank you.
> >>
> >> WBR,
> >> Alexey.
> >>
> >> On Nov 18, 2009, at 13:42 , Lohmann Kevin wrote:
> >>
> >>> Sorry, one of the attached files was wrong, this one is the right
> >> one.
> >>>
> >>> Cheers,
> >>> Kevin
> >>> <
> >>> MyProtocolParser
> >>> .java
> >>>> ------------------------------------------------------------------
> --
> >> -
> >>> To unsubscribe, e-mail: users-unsubscribe@...
> >>> For additional commands, e-mail: users-help@...
> >>
> >>
> >> --------------------------------------------------------------------
> -
> >> To unsubscribe, e-mail: users-unsubscribe@...
> >> For additional commands, e-mail: users-help@...
> >
> > <
> > code
> > .zip
> > >--------------------------------------------------------------------
> -
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: AW: AW: Multiple concurrent sendings vanish

2009-11-19T09:08:20Z

Hi Kevin,

looks like you don't have any bugs in the code :)
Grizzly by default kills idle connections after 30 seconds timeout. If
you're blocking threads for 7.5 seconds, it means that some connection
requests could not be processed during > 30 seconds, these connection
are getting closed... that's it.
To increase idle connection timeout to let's say 60 seconds - you can
do this:

private void configureServiceDispatcherHandler(
final int pServiceFileDownloadPort) {

if (this.mSelectorHandler == null) {

this.mSelectorHandler = new TCPSelectorHandler();

this.mSelectorHandler.setPort(pServiceFileDownloadPort);

this.mSelectorHandler
.setProtocolChainInstanceHandler(new
DefaultProtocolChainInstanceHandler() {
@Override
public ProtocolChain poll() {
return Server.this.mPROTOCOL_CHAIN;
}
});
+++ DefaultSelectionKeyHandler keyHandler = new
DefaultSelectionKeyHandler();
+++ keyHandler.setTimeout(60000); // 60 seconds
timeout
+++
this.mSelectorHandler.setSelectionKeyHandler(keyHandler);

}
}

WBR,
Alexey.

On Nov 19, 2009, at 10:23 , Lohmann Kevin wrote:

> Hi,
>
> I attached code, that reproduces the problem.
>
> Meanwhile I guess, it has something to do with time... In the class
> 'ServerForwardFilter' in the method 'doSomeThingWithMessage' there
> is a sleep of 7.5 seconds. If I change these seconds to 5,
> everything works fine.
>
> Also I played with setting the ReadThreadsCount for the controller.
> Setting the counter high (up to 30), there are many threads (62),
> but this setting works fine for my problem.
>
> I'm pleased to get any remarks.
>
> Thanks & cheers,
> Kevin
>
>> -----Ursprüngliche Nachricht-----
>> Von: Oleksiy.Stashok@... [mailto:Oleksiy.Stashok@...]
>> Gesendet: Mittwoch, 18. November 2009 17:47
>> An: users@...
>> Betreff: Re: AW: Multiple concurrent sendings vanish
>>
>> Hi Kevin,
>>
>> can you pls. send server and client code, which reproduces the issue.
>>
>> Thank you.
>>
>> WBR,
>> Alexey.
>>
>> On Nov 18, 2009, at 13:42 , Lohmann Kevin wrote:
>>
>>> Sorry, one of the attached files was wrong, this one is the right
>> one.
>>>
>>> Cheers,
>>> Kevin
>>> <
>>> MyProtocolParser
>>> .java
>>>> --------------------------------------------------------------------
>> -
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>
> <
> code
> .zip
> >---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

New GlassFish branch: 1_9_18i

2009-11-19T05:29:00Z

Hi,

we've cut Grizzly 1.9.18h to integrate it to GFv3. Hope it will be the
last integration :)
If not - please use 1_9_18i tag for additional GFv3 related fixes.

WBR,
Alexey.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[blog] Grizzly Servlet Container at Devoxx 2009

2009-11-19T03:46:33Z

Hi *

I've blogged on Grizzly Servlet Container at Devoxx this year. [1]
Contains slides of presentation.

Cheers.

[1] http://bit.ly/2ks81V

Re: [Jersey] Handing "Expect: 100-Continue" header

2009-11-19T02:02:26Z

On Nov 17, 2009, at 4:31 AM, Arulazi Dhesiaseelan wrote:

Hi,

How do I handle a Expect header in Jersey? Is this beyond the scope of Jersey (may be JAX-RS) and should be handled by the web server. Grizzly has a known bug [1].

Right.

I do see the response status [2] defined in ClientResponse.Status used when the expectation fails. But, not sure how this status could be sent from a resource.

100 continue is currently not supported by JAX-RS or Jersey. I would like to experiment by having a special 100-continue resource method set up that provides the necessary call-back function to return the response entity, if required. But that will require support from Grizzly (+ Grizzly in GF).

Paul.

Cheers,
Arul

[1] https://glassfish.dev.java.net/issues/show_bug.cgi?id=5320
[2] https://jersey.dev.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/api/client/ClientResponse.Status.html#EXPECTATION_FAILED

AW: AW: Multiple concurrent sendings vanish

2009-11-19T01:23:31Z

Hi,

I attached code, that reproduces the problem.

Meanwhile I guess, it has something to do with time... In the class 'ServerForwardFilter' in the method 'doSomeThingWithMessage' there is a sleep of 7.5 seconds. If I change these seconds to 5, everything works fine.

Also I played with setting the ReadThreadsCount for the controller. Setting the counter high (up to 30), there are many threads (62), but this setting works fine for my problem.

I'm pleased to get any remarks.

Thanks & cheers,
Kevin

> -----Ursprüngliche Nachricht-----
> Von: Oleksiy.Stashok@... [mailto:Oleksiy.Stashok@...]
> Gesendet: Mittwoch, 18. November 2009 17:47
> An: users@...
> Betreff: Re: AW: Multiple concurrent sendings vanish
>
> Hi Kevin,
>
> can you pls. send server and client code, which reproduces the issue.
>
> Thank you.
>
> WBR,
> Alexey.
>
> On Nov 18, 2009, at 13:42 , Lohmann Kevin wrote:
>
> > Sorry, one of the attached files was wrong, this one is the right
> one.
> >
> > Cheers,
> > Kevin
> > <
> > MyProtocolParser
> > .java
> > >--------------------------------------------------------------------
> -
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

code.zip (12K) Download Attachment

Re: Confusion on maven packaging/dependencies

2009-11-18T11:42:51Z

Hi,

Those dependencies need to be declared so bundling will include them, otherwise contents of them would not be present inside.
I'll ask Maven gurus on how to solve it if it is possible to solve.

Thanks,
Hubert.

On Wed, Nov 18, 2009 at 8:22 PM, Jonathan Gold <jgold.bg@gmail.com> wrote:

Hubert --

Thanks for that. That's what I was suspecting, but I was surprised to see that
declaring a dependency on only the bundle results in maven pulling -- and
thinking it needs -- the redundant jars which are actually subsumed in the
bundle.

Is this perhaps a bug in the pom for the grizzly-webserver artifact?

I notice that in the pomfile grizzly-webserver-1.9.18-e.pom, there are these
dependencies:

<dependencies>

<dependency>
<groupId>com.sun.grizzly</groupId>

<artifactId>grizzly-cometd</artifactId>
<version>${grizzly-version}</version>
</dependency>

<dependency>
<groupId>com.sun.grizzly</groupId>

<artifactId>grizzly-http-servlet</artifactId>
<version>${grizzly-version}</version>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>${servlet-version}</version>
</dependency>
</dependencies>

Is it possible that they could be the cause of the redundancy?

jon

On Tue, Nov 17, 2009 at 10:07:36PM +0100, Hubert Iwaniuk wrote:
> Hi Jon,
>
> That is because grizzly-webserver is a bundle package that means that is has
> packaged all it's dependencies within.
> So it should be enough to add only grizzly-webserver into classpath to get
> everything you need from grizzly :)
>
> HTH,
> Hubert.
>
>
> On Tue, Nov 17, 2009 at 6:49 PM, Jonathan Gold <jgold.bg@gmail.com> wrote:
>
> > Hi --
> >
> > I've searched through the users@ and dev@ lists, but couldn't seem to find
> > any
> > answers, so here goes.
> >
> > I'm building an application that uses the GrizzlyWebServer class to embed
> > grizzly, and using maven for the project. Before maven, I used
> > grizzly-webserver-1.9.18-e.jar, so I figured that's what I should stick
> > with in
> > the maven version, putting this in my pom:
> >
> > <dependency>
> > <groupId>com.sun.grizzly</groupId>
> > <artifactId>grizzly-webserver</artifactId>
> > <version>1.9.18-e</version>
> > </dependency>
> >
> > using the dev.java.net repo. Everything compiles and works fine, but what
> > I'm
> > noticing is that the classpath that maven assembles (via maven's dependency
> > plugin dependency:build-classpath) includes the webserver jar
> > as well as redundant jars:
> >
> >
> > .../.m2/repository/com/sun/grizzly/grizzly-comet/1.9.18-e/grizzly-comet-1.9.18-e.jar
> >
> > .../.m2/repository/com/sun/grizzly/grizzly-cometd/1.9.18-e/grizzly-cometd-1.9.18-e.jar
> >
> > .../.m2/repository/com/sun/grizzly/grizzly-framework/1.9.18-e/grizzly-framework-1.9.18-e.jar
> >
> > .../.m2/repository/com/sun/grizzly/grizzly-http/1.9.18-e/grizzly-http-1.9.18-e.jar
> >
> > .../.m2/repository/com/sun/grizzly/grizzly-http-servlet/1.9.18-e/grizzly-http-servlet-1.9.18-e.jar
> >
> > .../.m2/repository/com/sun/grizzly/grizzly-portunif/1.9.18-e/grizzly-portunif-1.9.18-e.jar
> >
> > .../.m2/repository/com/sun/grizzly/grizzly-rcm/1.9.18-e/grizzly-rcm-1.9.18-e.jar
> >
> > .../.m2/repository/com/sun/grizzly/grizzly-utils/1.9.18-e/grizzly-utils-1.9.18-e.jar
> >
> > .../.m2/repository/com/sun/grizzly/grizzly-webserver/1.9.18-e/grizzly-webserver-1.9.18-e.jar
> > .../.m2/repository/javax/servlet/servlet-api/2.5/servlet-api-2.5.jar
> >
> > Am I doing something wrong here? I realize the duplicate jars are okay
> > since no
> > matter which jar a class is loaded from, it's coming from the same grizzly
> > build. Still, it makes me uncomfortable having duplication, so wonder if
> > some
> > experienced maven or grizzly peeps can give me some input?
> >
> > jon
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Confusion on maven packaging/dependencies

2009-11-18T11:22:06Z

Hubert --

Thanks for that. That's what I was suspecting, but I was surprised to see that
declaring a dependency on only the bundle results in maven pulling -- and
thinking it needs -- the redundant jars which are actually subsumed in the
bundle.

Is this perhaps a bug in the pom for the grizzly-webserver artifact?

I notice that in the pomfile grizzly-webserver-1.9.18-e.pom, there are these
dependencies:

<dependencies>
<dependency>
<groupId>com.sun.grizzly</groupId>
<artifactId>grizzly-cometd</artifactId>
<version>${grizzly-version}</version>
</dependency>
<dependency>
<groupId>com.sun.grizzly</groupId>
<artifactId>grizzly-http-servlet</artifactId>
<version>${grizzly-version}</version>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>${servlet-version}</version>
</dependency>
</dependencies>

Is it possible that they could be the cause of the redundancy?

jon

On Tue, Nov 17, 2009 at 10:07:36PM +0100, Hubert Iwaniuk wrote:

> Hi Jon,
>
> That is because grizzly-webserver is a bundle package that means that is has
> packaged all it's dependencies within.
> So it should be enough to add only grizzly-webserver into classpath to get
> everything you need from grizzly :)
>
> HTH,
> Hubert.
>
>
> On Tue, Nov 17, 2009 at 6:49 PM, Jonathan Gold <jgold.bg@...> wrote:
>
> > Hi --
> >
> > I've searched through the users@ and dev@ lists, but couldn't seem to find
> > any
> > answers, so here goes.
> >
> > I'm building an application that uses the GrizzlyWebServer class to embed
> > grizzly, and using maven for the project. Before maven, I used
> > grizzly-webserver-1.9.18-e.jar, so I figured that's what I should stick
> > with in
> > the maven version, putting this in my pom:
> >
> > <dependency>
> > <groupId>com.sun.grizzly</groupId>
> > <artifactId>grizzly-webserver</artifactId>
> > <version>1.9.18-e</version>
> > </dependency>
> >
> > using the dev.java.net repo. Everything compiles and works fine, but what
> > I'm
> > noticing is that the classpath that maven assembles (via maven's dependency
> > plugin dependency:build-classpath) includes the webserver jar
> > as well as redundant jars:
> >
> >
> > .../.m2/repository/com/sun/grizzly/grizzly-comet/1.9.18-e/grizzly-comet-1.9.18-e.jar
> >
> > .../.m2/repository/com/sun/grizzly/grizzly-cometd/1.9.18-e/grizzly-cometd-1.9.18-e.jar
> >
> > .../.m2/repository/com/sun/grizzly/grizzly-framework/1.9.18-e/grizzly-framework-1.9.18-e.jar
> >
> > .../.m2/repository/com/sun/grizzly/grizzly-http/1.9.18-e/grizzly-http-1.9.18-e.jar
> >
> > .../.m2/repository/com/sun/grizzly/grizzly-http-servlet/1.9.18-e/grizzly-http-servlet-1.9.18-e.jar
> >
> > .../.m2/repository/com/sun/grizzly/grizzly-portunif/1.9.18-e/grizzly-portunif-1.9.18-e.jar
> >
> > .../.m2/repository/com/sun/grizzly/grizzly-rcm/1.9.18-e/grizzly-rcm-1.9.18-e.jar
> >
> > .../.m2/repository/com/sun/grizzly/grizzly-utils/1.9.18-e/grizzly-utils-1.9.18-e.jar
> >
> > .../.m2/repository/com/sun/grizzly/grizzly-webserver/1.9.18-e/grizzly-webserver-1.9.18-e.jar
> > .../.m2/repository/javax/servlet/servlet-api/2.5/servlet-api-2.5.jar
> >
> > Am I doing something wrong here? I realize the duplicate jars are okay
> > since no
> > matter which jar a class is loaded from, it's coming from the same grizzly
> > build. Still, it makes me uncomfortable having duplication, so wonder if
> > some
> > experienced maven or grizzly peeps can give me some input?
> >
> > jon
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

NO PROJECT GRIZZLY MEETING November 18, 2009

2009-11-18T09:10:52Z

Hello,
there will be no grizzly meeting today.

WBR,
Alexey.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...