Apart from sonic, has anyone used a library or dll that can receive events on a linux/unix platform and process them in a char abl session ?
Thanks
Are you excluding Fuse as well?
No, I want to include anything that will work - however, is there a
client that can be used within a progress chui session ?
On 3 July 2011 19:13, Thomas Mercer-Hursh
I have no personal experience, but I see nothing in the requirements which would present using http://www.oehive.org/node/1627 or http://www.oehive.org/node/1204 on any 10.2 platform.
It would be lovely for someone to get interested, contribute, and get the questions and issued sorted out on these so that we had a tool any of us could use without much question.
your wish is my command I am already looking into these. The first
is a bit of a concern because of the socket handling - it doesn't use
the read-handler options that it should.
the second is a very basic option (you will see that I already played
with it a while ago) but I'll bring it all up to date.
On 3 July 2011 19:57, Thomas Mercer-Hursh
Great. This would be a good OERAOSI infrastructure component. I think Richard would be happy to cooperate since improving the socket handling would only make their own installation and use better.
Had some disturbing and mixed results. A single consumer on a machine can eat as many messages as you want with no ill-effects. however, throw a couple of new consumers into the mix, and "odd" results happen. Some messages don't get consumed, and worse, all sessions hang until one of the sessions is closed. No error messages, no cpu spikes.
Replace with a .net c# stomp client, and all consumers seem to work fine.
I *really* hate abl sockets. Hate them.
I'm going to see if Greg will help me check out the code to see if there's anything that can be fixed.
Pity that PEG isn't searchable these days because I'm pretty sure there was some PEG traffic about needed improvements. If Greg is busy, you might try Richard.
I haven't looked at the Flusso one yet - they don't use read-handler
response procedures, so I'm worried about scalability.
On 5 July 2011 06:56, Thomas Mercer-Hursh
So, coming back to the original question, is there any mechanism (apart from sockets) that can be used on a unix/linux client to receive events from an external process ?
there was an attempt to make the full JMS specs available for ABL, the project is somehow in an 'idle' state but most of the functionality is there... i can push an source code update on sourceforge if you want to take a look.
input through named pipes might work but you'll enjoy it about as much as you like using sockets... still, I think the only option that could let you use asynchronous model is using sockets
Windows Character Client, OpenEdge 11 and the .NET Bridge
jmls wrote:
So, coming back to the original question, is there any mechanism (apart from sockets) that can be used on a unix/linux client to receive events from an external process ?
Sonic?
shudder
ha ha ha. Mike, this may come as a shock to you, prepare yourself ...
there ARE another OS's out there apart from windows ...
so, the original question began with "Apart from sonic," ...
done a quick code update, hope it's in an usable form
http://progress-jms.svn.sourceforge.net/viewvc/progress-jms/net.sourceforge.progress.jms/
done a quick code update, hope it's in an usable form
http://progress-jms.svn.sourceforge.net/viewvc/progress-jms/net.sourceforge.progress.jms/
jmls wrote:
So, coming back to the original question, is there any mechanism (apart from sockets) that can be used on a unix/linux client to receive events from an external process ?
Are there any 3rd party DLLs/SOs out there that you could use?
-- peter
Yeah, there's plenty. But how do I get them to raise an event in the ABL ?
abl : pub/sub (abl only)
windows .net : Subscribe (abl / .net)
windows activex : on.event
windows com : enable-events (activex/com)
*nix : ??
check also http://code.google.com/p/abl2stomp/.
I am using it during 9 monthes and transfering 1Gb of data every day.
Three separate implementations of stomp seems like a waste. How about a little cooperation and lets come up with one really good one?
I suspect that you will never get an agreement - the three are so different ...
On 6 July 2011 17:27, Thomas Mercer-Hursh
Just because they are different, doesn't mean they are different for good reasons.
Just because they are different, doesn't mean they are different for good reasons.
Is this based on a review of the three different ones? Do you have a favorite? If so, which one and why?
That's my point - they are different for good reasons. And those
reasons make a difference when choosing which version to use
On 6 July 2011 17:47, Thomas Mercer-Hursh
No, I have not reviewed them ... but I have seen the discussions on PEG about weaknesses of one or the other. I have seen the authors admit to those weaknesses and hope they would eventually be addressed, not defend their approach as the best possible one.
Socket code is notoriously problematic. Some of that is due to limitations in the platform since handling sockets is one of the strong use cases for multi-threading. Nevertheless, I do think there is good practice and not good practice that can be evaluated and ferreted out. No doubt each of these has something nice about it and would be better to have all of those nice things in one place than to have three implementations which all had some kind of compromises. Why is that controversial?
If there are some real differences in purpose ... which is easy to understand in a component for authentication or access control or something ... then there is a reason to support multiple flavors or options, but surely in handling a protocol like this there is a lot of code which is necessarily common.
I've looked at all three, and the JMS from Marian Edu, and I do have a
preferred one - but only because I have a very very fixed and simple
requirement (small, fast, very simple to use)
I have modified the version from Carl to suit my needs. I processed
over 6 million messages last night without losing a single one, so it
more than suits my (modest) needs.
In order of simplicity (which is not, of course, any indication of
code quality nor appropriateness) , I would rank them
1) A Stomp class for connecting to ApacheMQ (http://www.oehive.org/node/1204)
2) ABL2Stomp (http://code.google.com/p/abl2stomp/)
3) Progress Fuse Adapter Project (http://www.oehive.org/project/FuseAdapter)
4) JMS
What I really liked about #1 is that it is a single class, very simple
and easy to read and understand, and use.
What I am really liking about this (stomp) though, is that it is a
step towards Sonic. I think that now I could replace ActiveMQ entirely
with sonic without having to change my stomp classes. I think ...
Julian, Thanks for the list and your comments! Very much appreciated!
jmls wrote:
Yeah, there's plenty. But how do I get them to raise an event in the ABL ?
abl : pub/sub (abl only)
windows .net : Subscribe (abl / .net)
windows activex : on.event
windows com : enable-events (activex/com)
*nix : ??
So, has anyone got any insights or answers on events in a linux environment ?
I'd say you're on a good track with your 0MQ
yeah, but what I'm missing is how to get the event raised in the 4GL client.
Create persistent object and connect with it to mq server asynchronously. Listen for messages in queue as events and process them.
yeah, but what I'm missing is how to get the event raised in the 4GL client.
The .NET class seems to have a delegate for that purpose. My plan is to turn that into an event using an additional and trivial C# class.
that's what I'm doing at the moment with stomp and sockets.
however, I am having ramdom crashes in the client that cause a GPF and
was considering using something else that didn't involve 4GL sockets
this all raises another question - if, as expected, v11 allows char
clients to use .net, will the linux char clients be able to use the
mono framework ?
That raises all sorts of interesting options
Max,
been browsing your stomp code, and I see that whenever you want to send a message, you create a new connection, send and disconnect
You have had no performance issues with this ?
At the moment, I keep the connection alive for producers as well as consumers. It may be interesting to try your method.
Am I right in thinking that you also create a new connection for every subscription ?
this all raises another question - if, as expected, v11 allows char
clients to use .net, will the linux char clients be able to use the
mono framework ?
Certainly not - but we've been there before.
Mono is not a 1:1 replacement for .NET on the API level. It just provides a compatible runtime environment.
That raises all sorts of interesting options
agreed.
dang
I am using listener.p as background process, that gets files from mq. My tests shows, that it can process about 500mb a minute. It is more than enough for me. Check example/transfer catalog. It is my working code. Clients connects for messages every 5 minutes, read queries, execute it and send files back to listener.
I have specific very large messages. Upto 100mb. But you are right. For small messages it is kinda slow. So you have to use classes, not high level procedures and keep connection.
dang
Do you really see a business case for Progress Software? The GUI for .NET was built for solving the GUI issue. Once the bridge was there and reliable enough opening it up for wider use of .NET was a logical consequence and probably a piece of cake.
Doing it all again for Mono? Why? UI's on Linux? Who needs those? Competition for Sonic MQ? Certainly not!
the point is, though, that you have a separate connection for each producer and each subscription. My producers and consumers share a connection. I suspect that this is not optimal
I'm reworking the stomp stuff at the moment, will let you know how I get on
hence the "dang"
would be nice and useful. Especially for us geeks
would be nice and useful. Especially for us geeks
Buy more Progress stock. It's cheap right now...
Buying stock will only benefit the prior owner of the stock, not PSC. To help fund PSC one needs to buy more product.
Buying stock will only benefit the prior owner of the stock, not PSC. To help fund PSC one needs to buy more product.
When a company needs to serve stock holders, more geeks should become stock holders.
Feedback from stockholders is even less than the feedback from developers ...
Feedback from stockholders is even less than the feedback from developers ...
Knowing that you'll never stop, I'll give up... That comment was marked as a joke. Don't take it serious.
But I'm serious that I doubt there is a commercial interest for PSC to integrate Mono. Those few developers with interest in that won't make a difference.
Agreed that the motivation for PSC to support mono is low. The OEA implementation for 11 is encouraging, but unless mono support was something that an enthusiast could implement over a weekend, I think the distribution of desktops would need to change significantly. Actually, even if it just worked, it probably wouldn't be supported because of the testing cost it would imply.