 | |
#11
 
| |||
| |||
|
Re: jd3 & vb -
06-03-2005
, 03:28 AM
|
Chistophe Thanks you for your kind reply. Well, the library is registered and I can see it in the "Object browser" window with all its methods. About the "intellisense box", it shows me "D3Connection" (and the others jd3 classes) in the line: Dim con As [control-space] But in the line Set con = New [control-space] The intellisense box doesnt show it. Using jd3com.d3connection same result. May be this one is for one of our VB experts at CDP ! Thanks any way ! Cristian |
My VB is 6.0
There is NO parameter to D3Connection object.
I just forgot one detail, you must open the connection to the server:
con.open(servername,port,user,password,1)
#12
| |||
| |||
|
|
Christophe, this is as good a place as any to ask this question: If your socket server in D3 dies, can you start a new server on the same socket port? I've had this argument with RD for a long time but I haven't taken the time to check current platform behavior. I know in the past that if the D3 PIB running a server process dies that it takes with it the handle to the socket. D3 still "owns" the handle but no longer has a reference to it. The OS has no idea that the socket is unavailable, it still thinks the socket is in use and will therefore not allow a new server process to be started on that same port. The only remedy used to be to reboot D3, which then released all resources including the socket. I've written some very stable client and server code using D3 sockets but a long time ago I realized that if the D3 process failed for whatever reason, that my code would not be able to restart. I didn't want my phone to ring with an upset client, where I'd have to explain to them that they needed to reboot D3 in order to use my software again. So I decided to stop using D3 as a socket server and only make client connections From D3 into a network that handled things better. So after all of this I'd like to know if you've experienced any of this and how JD3 handles it? To test: start a JD3 server, then reset-user on the PIB. Using (kill -9) on the PID might be a good brutal test too. I'd do the testing myself but I simply don't have time to waste on stuff that I've already wasted so much time on so many years ago. I know RD hasn't touched this code in years but they maintain the problem doesn't exist. Sorry, but I'm not getting paid to do QA (anymore). FWIW, another argument against a D3-based socket server is that you can't hand off process handles like a web server does, so every connection must complete in a single-threaded fashion before another one can be used. The only alternative is to have multiple server processes all listening on different TCP/IP ports, which isn't practical. This problem can be worked around in Linux by linking a custom comms module into the D3 monitor, but that's not practical for production user sites either. Thanks for your comments. Tony |
On a unix system, killing D3 pibs (logoff, reset-user or kill -9) kill
also socket handle. So we can just "shutdown" the jd3 server and reboot
it. But if one client is already connected to the server, killing it not
always free the socket. So we have to really "kill -9" the d3 pib to
free it correctly. This is the hard way, but it works.
On a windows system, D3 has the problem you explain but not all the
time. Sometime just a logoff free correctly socket, only sometime. And
reboot D3 is the last and better solution.
Now, I know JD3 is not the perfect solution, not the more stable, the
stronger or more secure solution. I just wrote it on my own private
time, just to connect my prefered langage to D3 and because RD don't
seem to open D3 to other (exotic) langage (Java, python, php, ...)
I think your solution, using somthing like a "proxy" , more stable in
network-server then D3, is really the good one. RD themselves use it
with the flashconnect technology. But using this oblige to install 2
system on the server : D3 and "proxy". Should maintain proxy on
unix/windows OS, maybe using a langage that required other
library/runtime (Java, python, .NET)
Not a bad things, just more "complicated" than just a D3 basic program ;-)
Now, I have not so much time to dedicate to this kind of stuff. And at
work, we are using much more Universe, that offer really cool library to
connect to himself, so jd3 is no more needed to do my work, neither to
play with my prefered langage.
This is also why JD3 not really evolved since its birth ...
Always here to talk,
Christophe
#13
| |||
| |||
|
|
Tony Gravagno a écrit : Christophe, this is as good a place as any to ask this question: If your socket server in D3 dies, can you start a new server on the same socket port? I've had this argument with RD for a long time but I haven't taken the time to check current platform behavior. I know in the past that if the D3 PIB running a server process dies that it takes with it the handle to the socket. D3 still "owns" the handle but no longer has a reference to it. The OS has no idea that the socket is unavailable, it still thinks the socket is in use and will therefore not allow a new server process to be started on that same port. The only remedy used to be to reboot D3, which then released all resources including the socket. I've written some very stable client and server code using D3 sockets but a long time ago I realized that if the D3 process failed for whatever reason, that my code would not be able to restart. I didn't want my phone to ring with an upset client, where I'd have to explain to them that they needed to reboot D3 in order to use my software again. So I decided to stop using D3 as a socket server and only make client connections From D3 into a network that handled things better. So after all of this I'd like to know if you've experienced any of this and how JD3 handles it? To test: start a JD3 server, then reset-user on the PIB. Using (kill -9) on the PID might be a good brutal test too. I'd do the testing myself but I simply don't have time to waste on stuff that I've already wasted so much time on so many years ago. I know RD hasn't touched this code in years but they maintain the problem doesn't exist. Sorry, but I'm not getting paid to do QA (anymore). FWIW, another argument against a D3-based socket server is that you can't hand off process handles like a web server does, so every connection must complete in a single-threaded fashion before another one can be used. The only alternative is to have multiple server processes all listening on different TCP/IP ports, which isn't practical. This problem can be worked around in Linux by linking a custom comms module into the D3 monitor, but that's not practical for production user sites either. Thanks for your comments. Tony Well the problem with the socket is still there, but not always ... On a unix system, killing D3 pibs (logoff, reset-user or kill -9) kill also socket handle. So we can just "shutdown" the jd3 server and reboot it. But if one client is already connected to the server, killing it not always free the socket. So we have to really "kill -9" the d3 pib to free it correctly. This is the hard way, but it works. On a windows system, D3 has the problem you explain but not all the time. Sometime just a logoff free correctly socket, only sometime. And reboot D3 is the last and better solution. Now, I know JD3 is not the perfect solution, not the more stable, the stronger or more secure solution. I just wrote it on my own private time, just to connect my prefered langage to D3 and because RD don't seem to open D3 to other (exotic) langage (Java, python, php, ...) I think your solution, using somthing like a "proxy" , more stable in network-server then D3, is really the good one. RD themselves use it with the flashconnect technology. But using this oblige to install 2 system on the server : D3 and "proxy". Should maintain proxy on unix/windows OS, maybe using a langage that required other library/runtime (Java, python, .NET) Not a bad things, just more "complicated" than just a D3 basic program ;-) Now, I have not so much time to dedicate to this kind of stuff. And at work, we are using much more Universe, that offer really cool library to connect to himself, so jd3 is no more needed to do my work, neither to play with my prefered langage. This is also why JD3 not really evolved since its birth ... Always here to talk, Christophe |
reaffirms my current approach to development which is indeed to use
proxies for comms and connection pooling.
RD doesn't seem to believe me when I tell them things like this are
messed up. I'm one of the few people who actually takes the time to
explain problems like this to them so they assume it's just "a Tony
thing". (Yes Glen, I've mentioned you've had the same issues but it
didn't help.) I've explained that there are a number of products in
our market that have not been ported to D3 because some of their core
connectivity options don't work properly, they're not functional
enough, or the add-ons are too expensive. When people don't see
products ported to D3 it only reinforces the misconception that D3 is
inadequate or unpopular, and that only encourages migrations. So by
ignoring the few reports that they DO get on things like this, they
are sabotaging a lot of their own efforts to sell software and retain
a customer base.
Like many of you, I'm tired of beating my head against a wall, so when
I get a "we've never heard of that before" or "doesn't seem like a
problem to us" I'm not going to force bug reports down anyone's
throat, I'm off to find a different way to do things, including other
vendor platforms. You'll see more evidence of this shortly. But
before anyone gives me that "glad to see you've finally taken off the
rosey glasses" line, I just want you guys to recognize a pattern here.
I've tried for years to encourage you to report issues. I've
explained the process to get action items, and the voting process by
which RD determines problem severity and enhancement demand. I can't
use D3 for a lot of communications development because RD isn't
hearing from anyone else about blatent functionality issues, and I'm
pretty upset about that, especially considering options with some
other platforms are even more limited. I'm getting tired of hearing
from VARs and developers that some bug in D3 was never fixed so they
had to migrate to another platform - and then find out that they never
actually requested a fix for the problem. This happens a lot. So how
does anyone expect the problems to be fixed? Just look at this
situation with JD3, popular FREE software that essentially isn't
suitable for production use because no one is reporting a problem.
This situation only reinforces the "D3 can't do that" attitude and
limits the opportunities for D3 VARs. It's a defeatist,
self-fulfilling prophecy that causes many of us to abandon this
otherwise very capable platform. As you can see, I have issues with
RD policies too and I'm a thorn in their side when it comes to some
things, but when VARs and users decide to not report issues it only
reinforces their belief that they are doing things right, and I have
to back off because I have no ground to stand on.
Mark, here it is again, the "we don't know what we don't know" issue
that RD fails to even recognize. I've been telling ya for years bud,
it's just killing this platform.
T
#14
| |||
| |||
|
|
[original thread preserved, comments follow quotes] |
Quote:
|
RD doesn't seem to believe me when I tell them things like this are messed up. I'm one of the few people who actually takes the time to explain problems like this to them so they assume it's just "a Tony thing". (Yes Glen, I've mentioned you've had the same issues but it didn't help.) I've explained that there are a number of products in our market that have not been ported to D3 because some of their core connectivity options don't work properly, they're not functional enough, or the add-ons are too expensive. When people don't see products ported to D3 it only reinforces the misconception that D3 is inadequate or unpopular, and that only encourages migrations. So by ignoring the few reports that they DO get on things like this, they are sabotaging a lot of their own efforts to sell software and retain a customer base. Like many of you, I'm tired of beating my head against a wall, so when I get a "we've never heard of that before" or "doesn't seem like a problem to us" I'm not going to force bug reports down anyone's throat, I'm off to find a different way to do things, including other vendor platforms. You'll see more evidence of this shortly. But before anyone gives me that "glad to see you've finally taken off the rosey glasses" line, I just want you guys to recognize a pattern here. I've tried for years to encourage you to report issues. I've explained the process to get action items, and the voting process by which RD determines problem severity and enhancement demand. I can't use D3 for a lot of communications development because RD isn't hearing from anyone else about blatent functionality issues, and I'm pretty upset about that, especially considering options with some other platforms are even more limited. I'm getting tired of hearing from VARs and developers that some bug in D3 was never fixed so they had to migrate to another platform - and then find out that they never actually requested a fix for the problem. This happens a lot. So how does anyone expect the problems to be fixed? Just look at this situation with JD3, popular FREE software that essentially isn't suitable for production use because no one is reporting a problem. This situation only reinforces the "D3 can't do that" attitude and limits the opportunities for D3 VARs. It's a defeatist, self-fulfilling prophecy that causes many of us to abandon this otherwise very capable platform. As you can see, I have issues with RD policies too and I'm a thorn in their side when it comes to some things, but when VARs and users decide to not report issues it only reinforces their belief that they are doing things right, and I have to back off because I have no ground to stand on. Mark, here it is again, the "we don't know what we don't know" issue that RD fails to even recognize. I've been telling ya for years bud, it's just killing this platform. T |
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.