I have certified messaging enabled for TibcoRV and ledger file which is constantly growing causing my app to die eventually.
With full control of the box (access to TibRV web interface, ledger file itself) is it possible to determine what CMName used the client connected to our app which is not confirming the messages (i.e. we are waiting for ACK from)?
Thanks
There are at least two ways you can inspect a ledger file
Use a Hawk method (for example via Hawk Display) called reviewLedger. This is available if your application is built using TIBCO BusinessWorks (or TIBCO adapters)
Use the ledgerpeek command-line tool (staffware from TIBCO) to inspect the file
Related
Is there a conventional way to write a program such that commands can be issued to the program from the command line without a repl? For example, how you can send commands to a running nginx server using sudo /etc/init.d/nginx restart (or any other valid command besides restart)
One idea I had was having the long-running program create and monitor a unix socket that other programs can write to to send it commands. Another was to create a local server with a REST interface that can be sent commands that way, though that seems a bit gross.
What's the right way to do this?
Both ways are ok, and you could even consider using some RPC machinery, such as making your application serve JSONRPC on some unix(7) socket. Or use a fifo(7). Or use D-Bus.
A common habit on Unix is to have applications reload their configuration files on e.g. SIGHUP signal, and save some persistent state (before terminating) on SIGTERM. Read signal(7) (notice that only async-signal-safe routines can be called fro signal handlers; a good way is to only set some volatile sig_atomic_t variable inside the handler and test it outside). See also POSIX signal.h documentation.
You might make your application become a specialized HTTP server (e.g. using some HTTP server library like libonion) and give it some Web interface (or REST, or SOAP ...); the user (or sysadmin) will then use his browser to interact with your application.
You could make your server systemd compatible. (I don't know exactly what that requires, it is perhaps D-bus related).
You could embed some command interpreter (like Guile and Lua) in your app and have some limited kind of REPL loop running on some IPC like a socket or a fifo. Beware of nasty code injection.
I had a similar issue where I have a plethora of services running on any number of machines and each is in need of communicating with several others.
My main problem was not so much the communication between the services. That can be done with a simple message sent over a connection (as Basile mentioned, it can be TCP, UDP, Unix sockets, FIFOs...). However, when you have over 20 services, many of which need to communicate with several other services, you start having a headache on how to get all the connections right (I have such a system, although it has a relatively limited number of services, like just 10 and that's already very complicated).
So I created a process (yet another service) called Communicator. All services connect to the Communicator service and when they need to send a message, they include the name of the service they want to reach. The Communicator service is in charge of sending the message to the right place—i.e. it could be to another Communicator service running on a different computer. Communicator has a graph of all the services available on your network and knows how to send messages to them without your service having to know anything about all of that. Computing a graph can be really complex.
For the purpose, I created the eventdispatcher project. It is in C++, which may not be what you're interested in, although you could use it in other languages that interface with C/C++. The structure of the messages are "proprietary" (specific to the Communicator), but you can create any message you want. A message includes a name and parameters (param-name=value). The first version has a simple one line text communication system. The newer version accepts JSON as well (still must be one line of text per message).
The system supports TCP, UDP, Unix sockets, FIFO, and between threads, you can have thread safe fifos. It also understand signals (like SIGHUP, SIGTERM, etc.) It has a specific connection to listen for the death of a thread. It supports encryption over TCP via OpenSSL. The messages can automatically be dispatched (hence the current name of the library). Connections are assigned a timer. And there are CUI and GUI (Qt) extensions as well.
The one main point here is that all your connections can be polled (see poll()) and thus you can implement a system that reacts to events instead of a system which sleeps and checks for events, sleeps and check, etc. or worth, you have a single blocking connection and everything has to happen on that one connection or your service gets stuck. This is one reason Unix has been using signals since early version of Unix did not have select() nor poll().
I am working on a POC wherein I am trying to achieve SOAP over JMS. Basically I'll be submitting my SOAP messages directly to the jms queue and a consumer will further read these SOAP messages and process them. The reason we want to stick to SOAP is because it is a standard formatand we'll not have to do something extra to design a new standard form messages.
For this poc I am using the default messaging provider which comes by default with IBM websphere app server 8.5. I referred to the following and I am able to submit my messages to queue. The problem is that I expected the SOAP to stay as XML/String on my queue however it is getting converted into a byte message.
I want to check the message and its type on my queue using some kind of queue browser tool which could work with IBM WAS8.5 . I googled and found that there are a lot of Queue browser tools available for servers like Glassfish etc but I couldn't find any tool or option for IBM WAS8.5?
Can you please guide me on what I can do to ensure that my SOAP message stays as XML on JMS queue and any GUI tool/option I could use to see the message and its type on Queue ?
Regards
Aakash
You can use the SIB Explorer tool to view the messages on the queue in WAS. The link to the tool is here.
There is also the SIB Destination Handler tool that allows you to perform more actions on the messages that you might find useful for your issue (like printing out properties etc). The SIB Destination Handler tool can be found here.
In addition to tools mentioned by whitfiea you can use web admin console and go to:
Buses > myBus > Destinations > myQueue > Queue points >
myQueue#rad9vmNode02.server1-myBus > (switch to the Runtime tab) > Messages
then select the message. You should be able to see the message contents.
I am creating a gwt widget library for our internal use. I am asked to fire an event whenever any event occurs on any of the controls in my gwt widget which would then be listened to by the application or project that is using my widget. The concept seemed similar to the event bus that i previously used for my other gwt projects to communicate between different views displayed in different regions on the same page. That worked fine as i was using the same instance of event bus through out the application. But now I would be using a particular instance of the event bus in my project but the application consuming it will not be using the same instance. Do I go ahead and use it or is there an alternate way to fire events between different applications. Please help
First, what do you call "different applications" ? Will they be running in the same browser ? Will they be deployed on the same server ?
You can't use EventBus to communicate between your applications if they don't share a common EventBus.
If your applications are running in the same tab, you can store the EventBus in a static variable, and retrieve it from the other applications in the same tab.
If your applications are running in the same browser (on different tabs), you can use LocalStorage to communicate. You can have a look at :
Inter-tab communication using local storage
Using HTML5 Web Storage for Interprocess Communication
Sharing data across windows using localStorage.
GWT provides an implementation of LocalStorage (and SessionStorage) in com.google.gwt.storage.client.Storage.
If they aren't running in the same browser, you will have to do a round-trip to the server to communicate from one application to an other (using RPC to send the message, and RPC polling to check for new messages - or using server push techniques, see GWTEventService and ServerPushFAQ).
If they aren't deployed on the same server, you will have to do a round-trip to the server and to communicate between your servers (using sockets, RPC, webservices,...).
RabbitMQ to the rescue... it's the canonical solution for this type of problem.
http://www.rabbitmq.com/
It was created as a bus for software, much like a hardware bus is to a computer system.
I especially like the http://manning.com/videla/ book. It goes into detail about the approach, outlines source code and the architecture behind it. Very practical.
we are making some loging issue, where we need write the logentries in the DB. But the process run in a transaction and by rollback are our new logentries also deleted. can I make a write in DB out of the transaction? something like write in temptable with NO-UNDO option...? that the new logentries still remain in DB...?
Another possibility would be to use an app server. Transactions on app server sessions are independent from transactions in the original session (that's what the optional and redundant "DISTINCT TRANSACTION" syntax is all about).
Another option would be to use a simple messaging system. One very easy to setup and use option is STOMP. It is platform neutral and very easy to get going with.
Julian Lyndon-Smith posted the following on PEG about a month ago, and it really is as easy to setup and use as he says (I've tried it, I used ApacheMQ which is also very easy to setup and use):
Following on from presentations in Boston and Finland, dot.r is
pleased to announce the open source Stomp project, available
immediately.
Download from either http://www.dotr.com or
https://bitbucket.org/jmls/stomp , the dot.r stomp programs allow you
to connect your progress session to any other application or service
that is connected to the same message broker.
Open source, free message brokers that support Stomp are:
Fuse
(http://fusesource.com/products/fuse-mq-enterprise/) [a Progress company now owned by Red Hat inc]
Fuse MQ Enterprise is a standards-based, open source messaging platform that deploys with a very small footprint. The lack of license
fees combined with high-performance, reliable messaging that can be
used with any development environment provides a solution that
supports integration everywhere
ActiveMQ
Apache ActiveMQ (tm) (http://activemq.apache.org/)is the most popular
and powerful open source messaging and Integration Patterns server. Apache
ActiveMQ is fast, supports many Cross Language Clients and Protocols, comes
with easy to use Enterprise Integration Patterns and many advanced features
while fully supporting JMS 1.1 and J2EE 1.4.
Apache ActiveMQ is released under the Apache 2.0 License.
RabbitMQ
RabbitMQ is a message broker. The principal idea is pretty simple: it
accepts and forwards messages. You can think about it as a post
office: when you send mail to the post box you're pretty sure that Mr.
Postman will eventually deliver the mail to your recipient. Using this
metaphor RabbitMQ is a post box, a post office and a postman.
The major difference between RabbitMQ and the post office is the fact
that it doesn't deal with paper, instead it accepts, stores and
forwards binary blobs of data - messages.
Please feel free to log any issues on the
https://bitbucket.org/jmls/stomp issue system, and fork the project in
order to commit back all those new features that you are going to add
...
dot.r Stomp uses the permissive MIT licence
(http://en.wikipedia.org/wiki/MIT_License)
Have fun, enjoy !
Julian
Every change to the database must be part of a transaction. If you do not explicitly start one it will be implicitly started for you and scoped to the next outer block with transaction capabilities.
However and although I would not recommend you to, work with sub-transactions. You can invoke a sub transaction by explicitly specifying a DO TRANSACTION within the transaction scope. Although the database will never know about it, the client can roll back the sub transaction while the database can commit the transaction.
But in order to implement something like this you must master the concepts of transaction scope, block behavior and error handling.
RealHeavyDude.
Write your log entries to a no-undo temp-table.
When the code will commit a transaction, or transactions aren't active (transactionID = ?) have your code write the log entries out.
I don't think there is any way to do this in ABL as you planned either efficiently (sprinkling temp-table flushes or other tidbits all over the place is gross) or reliably (what if the application crashes with an un-flushed temp-table?), as others have mentioned. I would suggest making your complicated logging less coupled to your app by making the database writes asynchronous, occurring outside of your application if possible.
Since you're on Windows, you could change your logging to use the .NET log4net library instead of ABL constructs. log4net has a few appenders that would be useful:
AdoNetAppender which lets you log directly to a database
RemoteSyslogAppender which uses the syslog protocol, letting you log to an external Unix syslog or rsyslog daemon (rsyslog supports writing log messages to databases)
UDPAppender which sends the log messages via UDP packets somewhere else to be handled (e.g. a logFaces server, which supports writing to databases)
If you must do it in ABL then you could use a named output stream specifically for your log messages (OUTPUT TO STREAM) which writes to a specific location where an external process is listening to handle it. This file could be a pipe created by something like mkfifo or just a regular text file that is monitored for changes with inotify (not sure what the Windows equivalents of these are). This external process would handle parsing the messages and writing them to the database (basically re-inventing rsyslog).
I like the no-undo temp-table idea, just be sure to put the database write part in a "FINALLY" block in case of unhandled exceptions.
Does anybody have experience with configuring distribution lists (sending a message to one queue, and having that message be forwarded to several other queues) for Websphere MQ v7? I want to configure it on my queue manager, rather than the client having to know all the queues to send the messages to. Also, I would prefer not to use a topic, because I want to be able to manage each queue separately. Is there some configuration file, or some way to use WebSphere MQ Explorer to do this?
Thanks
A program that uses a distribution list doesn't have to "know" the queues it sends to in the sense of hard-coding the names. But it does have to supply the list of queue names. Typically you can place these into a namelist and have the sending program retrieve them there. When the program calls PUT it must also be prepared to parse a structure of return codes rather than a single MQRC.
However, you really should reconsider using a topic. You can create administrative subscriptions for each destination queue. This allows you to send the publications to any local or remote queue that you like. It also have the advantage of being able to add or delete destinations without having to restart - or worse, recompile - the sending application.
You can use WMQ Explorer either to manage a namelist or to manage the topic and administrative subscriptions. The topic/subscriptions method is the only way to do this purely through configuration. To use distribution lists requires a program specifically designed for the purpose.