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/
> openmeetings-web/src/main/java/org/apache/openmeetings/
> web/common/MainPanel.java#L133
> [2] https://github.com/apache/openmeetings/blob/4.0.2/
> openmeetings-core/src/main/java/org/apache/openmeetings/
> core/util/WebSocketHelper.java#L241
> [3] https://github.com/apache/openmeetings/blob/4.0.x/
> openmeetings-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
