How does lightstreamer do the filter?

gengliangyu2008

Dear Lightstreamer supporter.

I have a question when I read our company's codes about lightstreamer.

I am not clear how does the lightstreamer do the filter.

I just know that we will assemble a query in the front end and send it to the medataprovider.

We have a class named FilterChainAdapter.java , it extends the class LiteralBasedProvider.

In FilterChainAdapter, I notice that we overwrite two method:

@Override
public boolean isSelectorAllowed(String user, String item, String selector) {
LOGGER.debug("START XmlQueryDataProvider.isSelectorAllowed(..)");

try {
for(AbstractFilterManager filterManager : runnable) {
/*
the runnable is a list, we store several filter manager classes in it.
In this method, we just loop each the filter manager, and execute its constructFilterChain method.

*/
filterManager.constructFilterChain(user,item,selector, runnable);
}
} catch (Exception e) {
LOGGER.error("Exception in XmlQueryDataProvider:isSelectorAllowed ", e);
}

return true;
}

@Override
public synchronized boolean isSelected(String user, String item, String selector, ItemEvent event) {
/*
this method was called by each filter manager. But I am not clear its purpose.
*/
LOGGER.debug("START XmlQueryDataProvider.isSelected(..)");

if (!StringUtils.hasText(selector)) {
LOGGER.warn("No query string selector found. Update refused. " +
"You should be using LiteralBasedProfile or you have forgot to add the XML query.");
return false;
}

if(runnable.isEmpty()) {
LOGGER.error("There are no runnable FilterManagers...error");
return false;
}

LOGGER.debug("Running Filter Managers....");

try {
for(AbstractFilterManager filterManager : runnable) {
if(!filterManager.accepts(user, event)){
LOGGER.debug("Filter Rejected Event!" + event.getValueAsString("key"));
return false;
}
}

} catch (Exception e) {
e.printStackTrace();
LOGGER.error("Exception in XmlQueryDataProvider", e);
}

return true;
}

After execute these two methods, the result was filtered automatically. Without entering the subscribe method again that we defined in our data adapter class. So I am very puzzled about this.

Any one can explain this to me?? I am very urgent in my current project.

Thank you very much.

Gary

Mone

Hi,

subscription and selector-filtering (the one applied by the isSelected) happen in two very different moment in the life of a Lightstreamer adapter.

The subscription on the DataProvider for an item X is performed when the first client subscribes to such item X: after that the DataProvider should start producing updates for that item.
If other clients subscribe to item X the subscribe call is not issued on the DataProvider.
The Unsubscribe call for item X will be called on the DataProvider only when there are no more clients subscribed to such item.
The Subscribe will be called again on the first client that subscribes again to item X.

The isSelected method is called whenever a new update is injected by the DataProvider into its ItemEventListener. As you can see that method is bound to an item, an user and a selector: the method is called once per each client connected and subscribed to that item; so the method choose whenever to let the server send the update to a client or to block it.

HTH.

gengliangyu2008

Hi Mone，

Thank you very much for your reply. From you reply, I understand the difference between subscription and selector-filtering further.

But I am still not clear about the workflow of selector-filtering. I have searched all the documents in lightstreamer installation files, but I don't find that.

Can you give me a workflow chart about the selector-filtering?

Thanks & Regards
Gary

Mone

Note that the selector is sent by the client during table subscription; the selector is just a string, as it is handled by custom code it can be potentially anything.

Per each item/user combination the isSelectorAllowed method is called so you can avoid a user or item or combination from having selectors applied to their updates.

Then on each update the isSelected is called per each update/user

I don't have a workflow chart about selectors, please take a look at these javadoc: http://bit.ly/grxqRg

gengliangyu2008

Hi Mone,

The lightstreamer filter was done in the front end, not back end, right?

So if there are a lot of data in the front end, will there be a performance issue?

I have another question about the mechanism adapter-to-front end, as I know the adapter class is a singleton class, so when multiple users connects to the same page, and we need to display different data to different user, how can we do that?

And when one user left that page, the adapter will execute the unsubscribe method, so why other users still can work normally?

Thanks & Regards
Gary

Mone

The lightstreamer filter was done in the front end, not back end, right?

The isSelected method is part of the MetadataProvider that runs in process with the Lightstreamer server. The client receives only the filtered data

So if there are a lot of data in the front end, will there be a performance issue?

As said the filtering is done in the server, btw as stated in the previously linked javadocs the isSelected method should execute fast.

I have another question about the mechanism adapter-to-front end, as I know the adapter class is a singleton class, so when multiple users connects to the same page, and we need to display different data to different user, how can we do that?

there are some threads in the forum about this topic; see in example this one: http://goo.gl/t0gfm

And when one user left that page, the adapter will execute the unsubscribe method, so why other users still can work normally?

the subscribe method is called when a client subscribes to an item and no other clients are subscribed to that item.
the unsubscribe method is called when the last client unsubscribes from the item.
This flow is illustrated in the LS_HOME/DOCS-SDKs/Genral Concepts.pdf file