- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Java and JavaScript Asynchronous i/o, Garbage ...
Operating System - OpenVMS
1748200
Members
3864
Online
108759
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-20-2009 04:24 PM
тАО03-20-2009 04:24 PM
Re: Java and JavaScript Asynchronous i/o, Garbage Collection, Funtion Instance references
Hi Bojan,
I starting to think you sold me the dummy big time with FirFox.JSObject support :-)
For a possible FF work around please see: -
http://groups.google.com/group/comp.lang.javascript/msg/7c8f34311e797e79
I know I used up a fair bit of your time already but, in light of that work-around, if you could please help with any of the following questions I'd really appreciate it!
1) If I know that the only Thread that will callback to my static, named, JavaScript function from my Applet is the SocketReader thread, then can I not defeat the FF JSObject bug simply by originally receiving the outgoing, message-specific, and complex object in the Applet method as a generic Java "Object". That Object's properties and methods would be ignored and preserved as it passes from JS-Java-JS, at which stage is message-specific "callback" could be invoked. (Ok, maybe the "static" funtion should be defined using JSObject.getWindow().eval(defineFunctionHere) at Applet init() time, as per the example's naming convention/hashing.)
2) Do you think the HashCoding (I'm guessing this is for per JSObject inside per Applet uniqueness?) specific to the particular application? I'm also guessing they have multiple Java threads (and possibly multiple Applets) calling back to the same JavaScript functionality?
3) I'm once again worried about JS Garbage Collection of my Objects as there will no longer be any references to them except on the Java side, stuck in a LinkedList as their original Object. You may recall that you put my mind as ease with references to the JSObject source code. But will this Object-Referencing still hold true for vanilla Java Objects instead of JSObjects?
Cheers Richard Maher
PS. I've attached some documentation to give yo a better idea of what the server configuration would look like.
I starting to think you sold me the dummy big time with FirFox.JSObject support :-)
For a possible FF work around please see: -
http://groups.google.com/group/comp.lang.javascript/msg/7c8f34311e797e79
I know I used up a fair bit of your time already but, in light of that work-around, if you could please help with any of the following questions I'd really appreciate it!
1) If I know that the only Thread that will callback to my static, named, JavaScript function from my Applet is the SocketReader thread, then can I not defeat the FF JSObject bug simply by originally receiving the outgoing, message-specific, and complex object in the Applet method as a generic Java "Object". That Object's properties and methods would be ignored and preserved as it passes from JS-Java-JS, at which stage is message-specific "callback" could be invoked. (Ok, maybe the "static" funtion should be defined using JSObject.getWindow().eval(defineFunctionHere) at Applet init() time, as per the example's naming convention/hashing.)
2) Do you think the HashCoding (I'm guessing this is for per JSObject inside per Applet uniqueness?) specific to the particular application? I'm also guessing they have multiple Java threads (and possibly multiple Applets) calling back to the same JavaScript functionality?
3) I'm once again worried about JS Garbage Collection of my Objects as there will no longer be any references to them except on the Java side, stuck in a LinkedList as their original Object. You may recall that you put my mind as ease with references to the JSObject source code. But will this Object-Referencing still hold true for vanilla Java Objects instead of JSObjects?
Cheers Richard Maher
PS. I've attached some documentation to give yo a better idea of what the server configuration would look like.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-21-2009 12:03 PM
тАО03-21-2009 12:03 PM
Re: Java and JavaScript Asynchronous i/o, Garbage Collection, Funtion Instance references
Richard,
First, sorry for the troubles (please read once again the first line of my first post in this thread;).
Attached is a new revised version of the example. It has the workaround from your previous post incorporated. But it brings new troubles! IE6 does not work and returns a String instead a JSObject so another work around must be taken.
It was tested in FF 3.0.1 Linux , FF 2.0.0.10 Win, IE6 Win , Chrome.
The work around also solves your thoughts about references. The object is referenced in JS until you free it. I deleted the JS method "done" and replace it with a new Java method "free" which is also called when the message is GCed in Java.
In the example I opted for a slightly different method for naming. In the work around from your previous post the objects remain referenced for ever (in JS). In my example the "slots" are reused.
Abbout the uniquess of HashCoding see the description of the Object.hashCode in the Java API documentation. You will see that this is implementation specific but in most cases that is the address of the object in the real memory. But how is the address converted in a 64 bit system?
OK in my example I used the same method for the object in which the messages are held. This will probably solve the problem when you have two applets in the same page.
And please do not take it as a finished and fully tested example. It was semi black-box tested.
Bojan
First, sorry for the troubles (please read once again the first line of my first post in this thread;).
Attached is a new revised version of the example. It has the workaround from your previous post incorporated. But it brings new troubles! IE6 does not work and returns a String instead a JSObject so another work around must be taken.
It was tested in FF 3.0.1 Linux , FF 2.0.0.10 Win, IE6 Win , Chrome.
The work around also solves your thoughts about references. The object is referenced in JS until you free it. I deleted the JS method "done" and replace it with a new Java method "free" which is also called when the message is GCed in Java.
In the example I opted for a slightly different method for naming. In the work around from your previous post the objects remain referenced for ever (in JS). In my example the "slots" are reused.
Abbout the uniquess of HashCoding see the description of the Object.hashCode in the Java API documentation. You will see that this is implementation specific but in most cases that is the address of the object in the real memory. But how is the address converted in a 64 bit system?
OK in my example I used the same method for the object in which the messages are held. This will probably solve the problem when you have two applets in the same page.
And please do not take it as a finished and fully tested example. It was semi black-box tested.
Bojan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-22-2009 05:03 PM
тАО03-22-2009 05:03 PM
Re: Java and JavaScript Asynchronous i/o, Garbage Collection, Funtion Instance references
Hi Bojan,
Thanks very much for the new example!
I wasn't aware of the Stack class (which looks very useful) and I like the example of overiding the finalize() method to achieve Rundown Handler functionality.
What I'm going to do now is go away and work out where to stick the goal posts; it's all a bit liquid at the moment.
I will report back when I've firmed-up requirements/problem-specs.
Cheers Richard Maher
Thanks very much for the new example!
I wasn't aware of the Stack class (which looks very useful) and I like the example of overiding the finalize() method to achieve Rundown Handler functionality.
What I'm going to do now is go away and work out where to stick the goal posts; it's all a bit liquid at the moment.
I will report back when I've firmed-up requirements/problem-specs.
Cheers Richard Maher
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-08-2009 10:30 PM
тАО05-08-2009 10:30 PM
Re: Java and JavaScript Asynchronous i/o, Garbage Collection, Funtion Instance references
Hi Bojan,
I've come up with functionality that I think is pretty hot and hope to have something to show for my efforts shortly. (See other post on IE6 JSObject bug)
But in the meantime here is the work around that I'm using to get around the FireFox JSObject bug that we discussed previously.
Cheers Richard Maher
I wrote about: -
http://groups.google.com/group/comp.lang.javascript/msg/7c8f34311e797e79
> > Daniel's post shows up as 25/9/2008 so there's every chance that it's
state
> > of the art. Does anyone have any better/other/more-integrated ideas?
Daniel Pitts wrote: -
> It was state-of-the-art when I posted it. Since then, I've also run into
> what appears to be threading issues causing firefox to crash :-( It's
> unfortunate because every other aspect of our tool was targeting firefox.
In case it helps anyone, an alternative to Daniel's method of bypassing the
FF bug with JSObjects is simply to pass the JSObject into a Javascript
function and return it straight back as in: -
Tier3Client.launder =
function(jsobject) {
return jsobject;
}
8<-------------------
public int sendMessage (JSObject msgBuf,
String msgIn,
int windowSlotId)
throws IOException,
Tier3ClientException
{
System.out.println("In Session sendmessage");
WindowSlot windowSlot = getWindowSlot(windowSlotId);
rinseArgs[0] = msgBuf;
try {
cleanBuf = (JSObject)windowSlot.namespace.call("launder",
rinseArgs);
}
catch (Exception e) {
throw new Tier3ClientException("Unable to launder Message
Buffer", e);
}
Even though Internet Explorer doesn't suffer from the same bug as FireFox,
the work around is valid for both so, in this case, I haven't bothered to
conditionalize the code. IIRC Daniel's example didn't work on IE?
Obviously you could create the "launder" function on the fly with a unique
name via eval() rather than use a predefined static function.
I've come up with functionality that I think is pretty hot and hope to have something to show for my efforts shortly. (See other post on IE6 JSObject bug)
But in the meantime here is the work around that I'm using to get around the FireFox JSObject bug that we discussed previously.
Cheers Richard Maher
I wrote about: -
http://groups.google.com/group/comp.lang.javascript/msg/7c8f34311e797e79
> > Daniel's post shows up as 25/9/2008 so there's every chance that it's
state
> > of the art. Does anyone have any better/other/more-integrated ideas?
Daniel Pitts wrote: -
> It was state-of-the-art when I posted it. Since then, I've also run into
> what appears to be threading issues causing firefox to crash :-( It's
> unfortunate because every other aspect of our tool was targeting firefox.
In case it helps anyone, an alternative to Daniel's method of bypassing the
FF bug with JSObjects is simply to pass the JSObject into a Javascript
function and return it straight back as in: -
Tier3Client.launder =
function(jsobject) {
return jsobject;
}
8<-------------------
public int sendMessage (JSObject msgBuf,
String msgIn,
int windowSlotId)
throws IOException,
Tier3ClientException
{
System.out.println("In Session sendmessage");
WindowSlot windowSlot = getWindowSlot(windowSlotId);
rinseArgs[0] = msgBuf;
try {
cleanBuf = (JSObject)windowSlot.namespace.call("launder",
rinseArgs);
}
catch (Exception e) {
throw new Tier3ClientException("Unable to launder Message
Buffer", e);
}
Even though Internet Explorer doesn't suffer from the same bug as FireFox,
the work around is valid for both so, in this case, I haven't bothered to
conditionalize the code. IIRC Daniel's example didn't work on IE?
Obviously you could create the "launder" function on the fly with a unique
name via eval() rather than use a predefined static function.
- « Previous
-
- 1
- 2
- Next »
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP