Welcome to the new Gigaspaces XAP forum. To recover your account, please follow these instructions.

Ask Your Question
0

Question about remoting

We have a method in a worker service that's exposed through remoting. This method can also be invoked by a notify container running in a PU. We configured the notify container to use a single thread and FIFO to make sure we don't run into concurrency issue. As I understand, the space filter that remoting uses will also guarantee it's a sync operation. The question comes in when this method is invoked both by the notify container and remoting space filter at the same time. What will happen in this case? Will we have concurrency issue?

Thanks,

Simon h4. Attachments

[pu.xml|/upfiles/13759717934330765.xml]

{quote}This thread was imported from the previous forum. For your reference, the original is [available here|http://forum.openspaces.org/thread.jspa?threadID=2452]{quote}

asked 2008-07-11 11:26:21 -0600

noiseba gravatar image

updated 2013-08-08 09:52:00 -0600

jaissefsfex gravatar image
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

Which concurrency issues you mean? multiple threads accessing the same space object?
It is not clear how the space filter and the service remoting works with the notify container. Can you explain the relationship between these 2?

Having very small notify thread pool to 1 at the client side might impact the performance very much.
In any case , when getting notifications in FIFO mode , there is a dedicated thread at the client side that is triggering the listener based on the event ID. So there is no point to change this setting.

Shay

Attachments

  1. pu.xml

answered 2008-07-11 13:28:51 -0600

shay hassidim gravatar image
edit flag offensive delete link more

Comments

Here is the example of the worker service class:

{code} class WorkerService { public void processIncomingMessage(Message message) { if (message instanceof MessageTypeA) { processMessage((MessageTypeA) message); else if (message instanceof MessageTypeB) { processMessage((MessageTypeB) message); } }

public processMessage(MessageTypeA message) {
}

} {code}

processIncomingMessage method of the WorkerService class is configured as an event listener for a notify container in pu.xml. It will call the appropriate processMessage method based on the type of the message.

processMessage(MessageTypeA) method is also exposed via remoting. The concurrency issue comes in when both the notify container and remoting invokes processMessage(MessageTypeA) method at the same time because that method eventually updates space objects.

Thanks,

Simon h4. Attachments

[pu.xml|/upfiles/13759717943380309.xml]

noiseba gravatar imagenoiseba ( 2008-07-11 13:44:43 -0600 )edit

Interesting. We have here a generic processing worker.

I see here few issues: - if update operation triggers notify that performs update we will get into recursive calls. U need to limit the notification to happen only on write operation or not to perform update but write a different type of object , from a class type that does not extends the class type of the notification template (remember matching support subclassing). - how exactly u limit the amount of the threads? Have u modified the lrmi connection pool size? - why can't u have different notify container per message type? I understand that a single one makes it easy to maintain , but it might impact the concurrency and performance , especially with Fifo based notifications (unless u want fifo notifications across objects from different class type instances). Please note we improved the fifo notify handling with 6.5. Can u post your pu.xml? - why calling the same method from a remote method and a notify listener would cause a concurrency problem? As long as the business logic within the listener does not deal with the same data (see my first comment) u should not have a problem. - don't u need to consume the incoming messages ? Why polling container is not used? It sounds more relevant in your case (perform fifo take + update instead fifo notify + update). This will allow u to control the amount of instances running more easily and provide better durability (notifications are not durable and u might miss notifications in case of failover). Please note we do not support fifo take across objects from different classes (subclasses of the same parent class).

Shay h4. Attachments

[pu.xml|/upfiles/13759717945633531.xml]

shay hassidim gravatar imageshay hassidim ( 2008-07-11 15:56:19 -0600 )edit

{quote} Interesting. We have here a generic processing worker.

I see here few issues:

* if update operation triggers notify that performs update we will get into recursive calls. U need to limit the notification to happen only on write operation or not to perform update but write a different type of object , from a class type that does not extends the class type of the notification template (remember matching support subclassing).

{quote} We shouldn't have this problem. The notification template is configured to use the parent class of all the messages. Also the messages are never updated. {quote} * how exactly u limit the amount of the threads? Have u modified the lrmi connection pool size? * why can't u have different notify container per message type? I understand that a single one makes it easy to maintain , but it might impact the concurrency and performance , especially with Fifo based notifications (unless u want fifo notifications across objects from different class type instances). Please note we improved the fifo notify handling with 6.5. Can u post your pu.xml? {quote} We have one notify container for all the message types (done by configure the notification template with the parent class of the messages). Together with FIFO, we want to insure that the messages will be processed in order by one thread only because the messages are order dependent. The pu file is attached. {quote} * why calling the same method from a remote method and a notify listener would cause a concurrency problem? As long as the business logic within the listener does not deal with the same data (see my first comment) u should not have a problem. {quote} In our case, they can potentially access the exact same piece of data. {quote} * don't u need to consume the incoming messages ? Why polling container is not used? It sounds more relevant in your case (perform fifo take + update instead fifo notify + update). This will allow u to control the amount of instances running more easily and provide better durability (notifications are not durable and u might miss notifications in case of failover). Please note we do not support fifo take across objects from different classes (subclasses of the same parent class).

Shay {quote} We are planning to change the notify container to polling container after the last on-site visit from one of you guys.

Thanks,

Simon h4. Attachments

[pu.xml|/upfiles/13759717943916454.xml]

noiseba gravatar imagenoiseba ( 2008-07-11 16:37:01 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2008-07-11 11:26:21 -0600

Seen: 39 times

Last updated: Jul 11 '08