SFSRuntimeException: Join request discarded. User is already in a join transaction

Post here your questions about SFS2X. Here we discuss all server-side matters. For client API questions see the dedicated forums.

Moderators: Lapo, Bax

Jochanan
Posts: 79
Joined: 11 May 2018, 09:12

SFSRuntimeException: Join request discarded. User is already in a join transaction

Postby Jochanan » 05 Apr 2019, 12:38

Hello, i am having issues with joinRoom function, that is throwing me an exception. This is the relevant part of the stacktrace:

Code: Select all

lobbyDev2#29|com.smartfoxserver.v2.exceptions.SFSRuntimeException: Join request discarded. User is already in a join transaction: ( User Name: host5, Id: 7, Priv: 0, Sess: 85.70.227.39:54481 )
lobbyDev2#29|   at com.smartfoxserver.v2.api.SFSApi.joinRoom(SFSApi.java:849)
lobbyDev2#29|   at com.smartfoxserver.v2.api.SFSApi.joinRoom(SFSApi.java:813)
...
lobbyDev2#29|   at com.smartfoxserver.v2.extensions.SFSExtension.handleClientRequest(SFSExtension.java:208)
lobbyDev2#29|   at com.smartfoxserver.v2.controllers.v290.ExtensionReqController.processRequest(ExtensionReqController.java:174)
lobbyDev2#29|   at com.smartfoxserver.v2.controllers.v290.ExtensionReqController$1.run(ExtensionReqController.java:68)
lobbyDev2#29|   at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
lobbyDev2#29|   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
lobbyDev2#29|   at java.lang.Thread.run(Thread.java:745)


How is it possible?
Based on the stack trace, I can see. that client requests are asynchronous and multithreaded. joinRoom function is not? Why?
Why the joinRoom is not set as synchronized, which would solve the issue with multithreading.
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: SFSRuntimeException: Join request discarded. User is already in a join transaction

Postby Lapo » 05 Apr 2019, 13:48

Hi,
Join requests must be sent one at a time. If you're in the middle of a JoinRoom request you can't request another join.
Simply wait for the corresponding event before you join the next Room.

Making the request synchronized in the API could block the current thread for a relatively long time, which would cause other problems.

Cheers
Lapo
--
gotoAndPlay()
...addicted to flash games
Jochanan
Posts: 79
Joined: 11 May 2018, 09:12

Re: SFSRuntimeException: Join request discarded. User is already in a join transaction

Postby Jochanan » 05 Apr 2019, 14:38

The wait, that you suggest would not cause block of the current thread for a relatively long time?
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: SFSRuntimeException: Join request discarded. User is already in a join transaction

Postby Lapo » 05 Apr 2019, 14:58

No, because the calls are asynchronous. Threads don't block.
Lapo

--

gotoAndPlay()

...addicted to flash games
Jochanan
Posts: 79
Joined: 11 May 2018, 09:12

Re: SFSRuntimeException: Join request discarded. User is already in a join transaction

Postby Jochanan » 05 Apr 2019, 15:06

Which calls are asynchronous, handleClientRequest?

Multiple client requests leads to joining the room, so how would you implement the waiting you have suggested?
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: SFSRuntimeException: Join request discarded. User is already in a join transaction

Postby Lapo » 05 Apr 2019, 15:26

I think there's a misunderstanding here, let me clarify.
The error message above indicates that a client has sent a second JoinRequest while the previous one hasn't completed yet.

What I am suggesting to do the is following (from client side):

-> Send JoinRequest
<- Wait for SFSEvent.ROOM_JOIN (or ROOM_JOIN_ERROR)
-> Send JoinRequest
<- Wait for SFSEvent.ROOM_JOIN (or ROOM_JOIN_ERROR)

In other words if you need to join multiple Rooms wait for the whole operation to complete before sending the next join req.

Makes sense?
Lapo

--

gotoAndPlay()

...addicted to flash games
Jochanan
Posts: 79
Joined: 11 May 2018, 09:12

Re: SFSRuntimeException: Join request discarded. User is already in a join transaction

Postby Jochanan » 05 Apr 2019, 15:39

Makes sence, but not in our case, because that is not how our client does it.

We just cannot do that on client side, because the client is not the only iniciator of the room join.
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: SFSRuntimeException: Join request discarded. User is already in a join transaction

Postby Lapo » 06 Apr 2019, 08:10

Can you please give us a step by step description of how to reproduce this issue?
Also specify the client type and API version.

Thanks
Lapo

--

gotoAndPlay()

...addicted to flash games
Jochanan
Posts: 79
Joined: 11 May 2018, 09:12

Re: SFSRuntimeException: Join request discarded. User is already in a join transaction

Postby Jochanan » 08 Apr 2019, 08:31

REQUIREMENTS
1. There are two players per room, both players have to agree to play a game to initiate a game (and create a room)
2. Any playes may play any number of game simultaneously

Simple scenario
1. Player A opens a game request with multiple other players (player B, Player C, ... , Player X)
2. All other players (Player B, Player C, ... Player X) confirms a play at the same time
3. Server creates a new room for Player A - Player B, Player A - Player C, ..., Player A - Player X. Because server is multithreaded, those confirms may be handled simultaneously.
4. SFSRuntimeException: Join request discarded. User is already in a join transaction

This is a very simple scenario, that is just to demonstrate how easily can SFSRuntimeException: Join request discarded happen.
Our case are much more complex, we have multiple game tipes, which trigger room create on multiple conditions...
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: SFSRuntimeException: Join request discarded. User is already in a join transaction

Postby Lapo » 08 Apr 2019, 10:11

Thanks for the clarification.

In this particular scenario since you're creating and joining multiple Rooms at once you will need to make the code work serially, rather than in parallel.

You can create a global lock in your main Extension:

Code: Select all

Lock joinLock = new ReentrantLock();

and use it to synchronize the Room creation code such as this:

Code: Select all

joinLock.lock();

try
{
   // ... Create Room and join ...
}

finally
{
    joinLock.unlock();
}

Hope it helps
Lapo

--

gotoAndPlay()

...addicted to flash games
Jochanan
Posts: 79
Joined: 11 May 2018, 09:12

Re: SFSRuntimeException: Join request discarded. User is already in a join transaction

Postby Jochanan » 08 Apr 2019, 10:38

What is the difference between solution you proposed and making joinRoom synchronized on your end?
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: SFSRuntimeException: Join request discarded. User is already in a join transaction

Postby Lapo » 08 Apr 2019, 19:02

The difference would be to kill the performance for all the cases in which synchronization is not necessary, which is 95%.
In fact this particular issue has probably never been discussed before, because it's very niche.

Cheers
Lapo

--

gotoAndPlay()

...addicted to flash games
Jochanan
Posts: 79
Joined: 11 May 2018, 09:12

Re: SFSRuntimeException: Join request discarded. User is already in a join transaction

Postby Jochanan » 09 Apr 2019, 06:54

Lapo 2010:
In general I don't like the idea. Multithreading offers scalability. Forcing the game logic to run sequentially would pose possible risks of inability to scale. Honestly with today's Java5/6 new concurrent collections and tools handling concurrency is not much of a pain, most of the hard work is done for you behind the scenes.

Lapo 2019:
Just do it in a single thread

SfS Manual:
It is important to note that the SFS2X API already take care of concurrency most of the times: all the calls provided bye the main SFSApi class are thread safe and the same goes for the Game API and Buddy List API.


SfS Reality:
In reality, there are several parts of the system, that cannot handle concurency correctly

It seems to me, that you are always suggesting a solutions, which outcome are 100% work on users an 0% work on SfS.

May i ask you for a code snippet of SFSApi.joinRoom? I am concerned, that it is not thread safe at all.
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: SFSRuntimeException: Join request discarded. User is already in a join transaction

Postby Lapo » 09 Apr 2019, 14:59

SfS Reality:
In reality, there are several parts of the system, that cannot handle concurency correctly

Why not?
Not handling concurrency correctly means corruption of data. This is not the case. You're simply warned by an error.
Why don't you use the solution I provided?

It seems to me, that you are always suggesting a solutions, which outcome are 100% work on users an 0% work on SfS.

I don't understand what point are you trying to make.
As I've explained, the kind of change you're suggesting would introduce a bottleneck for all common cases to solve a corner case.
It's not a good trade-off for multiple reasons.

1) In our experience it's a very rare scenario the one you've described, in fact in over 10 years of SFS2X existing I don't think I've ever seen this particular case. You could be joining multiple Room at once via for loop calling SFSApi.joinRoom() and still be perfectly safe as you would be running in the same thread. Your case definitely falls among the <1% of corner cases.

2) It would cause a degradation of performance as already explained

3) The solution I proposed requires adding three lines of code, which doesn't sound like a massive amount of extra work.

Let us know.
Lapo

--

gotoAndPlay()

...addicted to flash games
Jochanan
Posts: 79
Joined: 11 May 2018, 09:12

Re: SFSRuntimeException: Join request discarded. User is already in a join transaction

Postby Jochanan » 10 Apr 2019, 07:48

Lapo wrote:
SfS Reality:
In reality, there are several parts of the system, that cannot handle concurency correctly

Why not?
Not handling concurrency correctly means corruption of data. This is not the case. You're simply warned by an error.
Why don't you use the solution I provided?


Could you share a code snippet of joinRoom api implementation that proves, that it is in fact thread safe? I have seen something on the internet, which was not thread safe at all. Could you prove me wrong?

Return to “SFS2X Questions”

Who is online

Users browsing this forum: No registered users and 50 guests