Here are the result of my investigation: Wicket is super fast on WebSockets
All my performance issues were caused by bad performance of Hazelcast IMap
(I have used default configuration)
Sorry for the noise
On Thu, Mar 15, 2018 at 11:29 PM, Maxim Solodovnik <solomax...@gmail.com>
wrote:
> 20 users has same pageId == 0, different sessionId, so page instances are
> different
> I thought the issue is caused by NoVersionMapper, but this seems to not
> the case .....
> Will continue debugging
> Any hints/pointers are highly appreciated
>
> On Thu, Mar 15, 2018 at 3:12 PM, Maxim Solodovnik <solomax...@gmail.com>
> wrote:
>
>> Hello Martin,
>>
>> Here are code examples (maybe I'm misusing something)
>>
>> I'm adding WebSocketBehavior to our MainPanel [1]
>> I'm using following code [2] to send messages to all "room clients" (send
>> to subset of IWebSocketConnectionRegistry)
>>
>> To test I'm running 20 chromium browsers with clean and initially empty
>> temp workspaces (being dropped on each run)
>>
>> I also have added sort of timing (basic implementation log.warn of the
>> result of System.currentTimeMillis())
>>
>> default solution [2] totally blocks UI and logs maximum working
>> time: 90.966sec
>>
>> So I did [3] (basically move all sending code to new Thread)
>> This partially unblock UI and slightly reduces delays (the maximum
>> reported is 78.373sec)
>>
>> Next I tried to add custom executor:
>> WebSocketSettings.Holder.get(this).setSendPayloadExecutor(new Executor()
>> {
>> @Override
>> public void run(Runnable command) {
>> final WebSession ws = WebSession.get();
>> final RequestCycle rc = RequestCycle.get();
>> new Thread(() -> {
>> ThreadContext.setApplication(Application.this);
>> ThreadContext.setSession(ws);
>> ThreadContext.setRequestCycle(rc);
>> command.run();
>> }).start();
>> }
>> });
>>
>> This totally break everything and all I got it is "
>> CouldNotLockPageException" exceptions ...
>>
>> Maybe my code for message sending is invalid?
>>
>> [1] https://github.com/apache/openmeetings/blob/4.0.x/openme
>> etings-web/src/main/java/org/apache/openmeetings/web/
>> common/MainPanel.java#L133
>> [2] https://github.com/apache/openmeetings/blob/4.0.2/openme
>> etings-core/src/main/java/org/apache/openmeetings/core/util/
>> WebSocketHelper.java#L241
>> [3] https://github.com/apache/openmeetings/blob/4.0.x/openme
>> etings-core/src/main/java/org/apache/openmeetings/core/util/
>> WebSocketHelper.java#L244
>>
>> On Thu, Mar 15, 2018 at 2:56 PM, Martin Grigorov <mgrigo...@apache.org>
>> wrote:
>>
>>> Hi Maxim,
>>>
>>> Each WebSocket connection locks only one page instance for the processing
>>> time.
>>>
>>> "20+ simultaneous connects" - I guess this is 20 connections by different
>>> users, not 20 in the same page instance, right ?
>>> Because I do not expect 20 different users to interfere to each other.
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>> Looking for a remote position with Wicket ? Contact me!
>>> https://twitter.com/mtgrigorov
>>>
>>>
>>> On Thu, Mar 15, 2018 at 7:58 AM, Maxim Solodovnik <solomax...@gmail.com>
>>> wrote:
>>>
>>> > Hello All,
>>> >
>>> > I'm trying to migrate from WebSocketBehavior to WebSocketResource due
>>> to
>>> > huge performance degradation starting 20+ simultaneous connects
>>> > Right now I see no way to process the messages "per client"
>>> >
>>> > Maybe it would be possible to have the power of these 2 approaches?
>>> > Or maybe there is the way to reduce lock time?
>>> >
>>> > I tried to implement
>>> > multi-threaded WebSocketSettings.Holder.get(t
>>> his).setSendPayloadExecutor,
>>> > but this leads to lots of CouldNotLockPageException ...
>>> >
>>> >
>>> > On Thu, Mar 1, 2018 at 3:41 PM, Maxim Solodovnik <solomax...@gmail.com
>>> >
>>> > wrote:
>>> >
>>> > > Hello Martin,
>>> > >
>>> > > Thanks a lot for the answer
>>> > > I do remember it was discussed, and I do remember WebSocketResource
>>> is
>>> > > more performant,
>>> > > this is why i thought it would be good to have "resource" for speedy
>>> > > json and "behavior" for component updates etc.
>>> > >
>>> > > This is also mentioned in guide:
>>> > > https://ci.apache.org/projects/wicket/guide/8.x/single.html#
>>> _how_to_use
>>> > >
>>> > > "Wicket allows one thread at a time to use a page instance to
>>> simplify
>>> > > the usage of the pages in multithreaded enviroment. When a WebSocket
>>> > > message is sent to a page Wicket needs to acquire the lock to that
>>> > > page to be able to pass the IWebSocketMessage to the
>>> > > WebSocketBehavior. This may be problematic when the application needs
>>> > > to send many messages from the client to the server. For this reason
>>> > > Wicket provides WebSocketResource"
>>> > >
>>> > >
>>> > >
>>> > > On Thu, Mar 1, 2018 at 2:04 AM, Martin Grigorov
>>> > > <martin.grigo...@gmail.com> wrote:
>>> > > > Hi Maxim,
>>> > > >
>>> > > > This has been discussed in the past.
>>> > > > Please search the archives.
>>> > > > I see no reason why to have more than one connection per page.
>>> > > >
>>> > > > On Feb 28, 2018 19:44, "Maxim Solodovnik" <solomax...@gmail.com>
>>> > wrote:
>>> > > >
>>> > > >> It seems ConnectionRegistry should also be changed in the case of
>>> 2 or
>>> > > >> more websockets are opened :(
>>> > > >> will try with one websocket for now ...
>>> > > >>
>>> > > >> sorry for the noise
>>> > > >>
>>> > > >> On Thu, Mar 1, 2018 at 12:38 AM, Maxim Solodovnik <
>>> > solomax...@gmail.com
>>> > > >
>>> > > >> wrote:
>>> > > >> > Hello All,
>>> > > >> >
>>> > > >> > As far as I can see from the code
>>> > > >> > right now it is not possible to have multiple WebSockets on the
>>> page
>>> > > >> >
>>> > > >> > WebSocketResource and WebSocketBehavior
>>> > > >> >
>>> > > >> > Maybe it worth to extends API to allow such configuration?
>>> > > >> > I can create PR :)
>>> > > >> >
>>> > > >> > --
>>> > > >> > WBR
>>> > > >> > Maxim aka solomax
>>> > > >>
>>> > > >>
>>> > > >>
>>> > > >> --
>>> > > >> WBR
>>> > > >> Maxim aka solomax
>>> > > >>
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > > WBR
>>> > > Maxim aka solomax
>>> > >
>>> >
>>> >
>>> >
>>> > --
>>> > WBR
>>> > Maxim aka solomax
>>> >
>>>
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
>
>
>
> --
> WBR
> Maxim aka solomax
>
--
WBR
Maxim aka solomax
