ER bind problem

gerald.logor

hi all.

Our web-app is set up to use a "master" engine inside a main (index.html) page. This engine is being referenced throughout the application by its children windows, using the "seekEngine".
The problem is, when we open a lot of this children windows and perform a lot of item-subscription activities, it gives the alert error of "ER Bind unable to find engine".
Sorry if maybe what I described above is not much of a helper in diagnosing this problem.

Any suggestions/thoughts on this?

I'm using the Moderato 3.4.8_build_1398 version, and below are some snippets of mine.
Thanks in advance.


//***************************************

//Ex: inside main (master) page
...
...
var lsPage = new PushPage();
lsPage.context.setDomain("my.domain.com");
lsPage.onEngineCreation = startEngine;
lsPage.bind();
lsPage.createEngine("MyEngine", "LS/","SHARE_SESSION");

function startEngine(eng) {
	eng.policy.setMaxBandwidth(30);
	eng.policy.setIdleTimeout(30000);
	eng.policy.setPollingInterval(1000);
	eng.connection.setLSHost("win.my.domain.com");
	eng.connection.setLSPort(8080);
	eng.connection.setAdapterName("MYADAPTER");
	eng.changeStatus("STREAMING");
}
...
...

//***************************************

//Ex: inside children windows
...
...
var lsPage = new PushPage();
var txtDomain = "my.domain.com";
var debugAlerts = true;
var remoteAlerts = false;
var pushHost =null;
if (location.href.indexOf(txtDomain) > -1) {
	lsPage.context.setDomain(txtDomain);
	debugAlerts = false;
	remoteAlerts = true;
} 
else {
	lsPage.context.setDomain(txtDomain);
}
lsPage.context.setDebugAlertsOnClientError(debugAlerts);
lsPage.context.setRemoteAlertsOnClientError(remoteAlerts);
lsPage.bind();
lsPage.seekEngine("MyEngine", self);
...
...

Mone

Hello,

first of all there is an error in the seekEngine call. You pass to that method a self pointer but you should pass to it a pointer to the master pushpage's window. By the way the library should be able to reach the master pushpage with the name you give (that's correct)
i.e. If the second pushpage is an iframe inside the master one, than you could call
[syntax="JS"]lsPage.seekEngine("MyEngine",self.parent);[/syntax]
see seekEngine doc for further details.

returning back to your issue I'm confident that is something you should not worry about.
The "unable to find the engine..." alert is a warning message that appears if after some efforts the page wasn't able to bind to the engine. Usually pages showing that alert after a while succed to find their engine and then them receive their data correctly. This issue is due to downloading times.
Is this your case? If it is, just disable the debug alerts on your production environment and everything will be ok.
see http://www.lightstreamer.com/docs/client_web_jsdoc/Context.html#setDebugAlertsOnClientError

let me know if that's not your case (i.e. pages showing the alert never start streaming) or if you want further clarification.
HTH.

gerald.logor

Thanks for the input on the "seekEngine" parameter. We'll try that.
Regarding your comment,
>>>.....Usually pages showing that alert after a while succeed to find their engine and then them receive their data correctly.
.....
>>>

Unfortunately, this is not the case. When the alert shows up (and we're still trying to figure out which page triggers the alert), basically it stalled the streaming throughout the entire active LS pages. (ie. the master push-page, as well as its children), therefore, the streaming contents are gone. And in about 3-4 seconds of interval, it pops a new alert with the same message. (I assume that the page is trying to reconnect/re-stream in the given interval).
Our current solution is to close all the children pages, logout of the webapp (destroying the LS engine and session from the master push-page), and log back in again. Then, it would startup and stream normally. Moreover, another solution that I noticed, is that when all the children pages are closed (no references are being made to the master push-page engine), I waited for about 4 seconds, and then I refresh the main page, and it streams the data normally again.

The problem is that we don't want to logout of the app, as well as losing important presentation data, when the alert is presented.

I'll try to disable the debug alerts (as you've suggested), but like I've mentioned, after the alert, the pages never succeed in retrying to stream the data. Thus, eliminating the alert would not cause the data to be sent. But I'll give it a shot nevertheless.

Thanks again.

Regards

Mone

and we're still trying to figure out which page triggers the alert

you can customize the message to identify which page is triggering the error. Just implement the onClientError callback on your code:
[syntax="JS"]lsPage.onClientError = function(mex) {
alert("PageA\n"+mex);
};
lsPage.seekEngine("MyEngine",self.parent);[/syntax]

basically it stalled the streaming throughout the entire active LS pages

I've never seen a behaviour like this. Which browser are you using? Is it possible that the stalled connection is not the same issue? (e.g.: the IE links problem )
Please note that once a connection is stalled if it become disconnected then the client will reconnect automatically. See http://www.lightstreamer.com/docs/client_web_jsdoc/Policy.html#getTimeoutForReconnect

Please try to understand which is the frame that fails, than try to remove it to see if the two issues (alert message and connection stalled) are related.
We will then try to investagate it further.

ddhanis

Hi,

I tried to use this,

lsPage.onClientError = function(mex) {
alert("PageA\n"+mex);
};

but when event happened it didn't show any information about the page causing the causing the problem.

Please advise.

Mone

hi,

you should customize the alert text in a different manner per each page so that you can understand which page is showing it.
So on one page will be
[syntax="JS"]lsPage.onClientError = function(mex) {
alert("PageA\n"+mex);
};[/syntax]
on another one will be
[syntax="JS"]lsPage.onClientError = function(mex) {
alert("PageB\n"+mex);
};[/syntax]
and so on.

is this not possible?