I read that each message has its own way of using lparam and wparam. I couldn't find any convention about when we pass pointers, who is responsible for memory handling. Should the caller keep track or the message handler should take care of it? I sense that in messaging model it would be hard for caller to manage the memory. Because it won't know when the resource is no longer needed for the message handler. On the other hand that is known as a bad practice in C++ programming. Would you please help me on this?
I conclude it is completely by code designer on how message parameters are managed. I also note that if a message is posted aysnc either the resource should be freed by message handler or somehow sender must be signaled by message handler that the resource passed in lparam or wparam is no longer needed.
Related
With my team, we are trying to set up an error handling policy common to several microservices (for the majority of cases). My team and I are struggling to understand the difference between a listener-level error handler and a container-level error handler. What are the real implications behind this choice? Is it only the fact that the container error handler does not have access to the message?
The KafkaListenerErrorHandler allows a more fine grained exception handling, we can use on the content of the exception to define if it is retryable or not.
In the error handler containers it seems more complicated, before it was possible to provide a custom classifier but not anymore, we can only pass a classification map.
In the past we used to use the SeekToCurrentErrorHandler (now DefaultErrorHandler), which was recommended in the documentation. I saw another StackOverflow thread related to this topic but I can't quite make the connection with our questions. The documentation doesn't seem to address the implications of this choice.
Thank you very much.
The main use case for the listener-level error handler is for request/reply processing; it allows the error handler to send some other result to the sender to indicate the request wasn't processed. As you say, it also provides access to the spring-messaging converted Message<?> (possibly with a converted payload); e.g. for logging; it can re-throw the exception to invoke the container EH.
Regarding classification, that change was to allow classifications to be added and removed dynamically. If you prefer to have the old behavior (allowing a custom classifier) to be restored, please open an issue on GitHub.
Trying to fix a problem in a classic ASP application, however I am inexperienced. Tried to find more info but was unable to.
The app instantiates a COM object for data retrieval which is not thread-safe, so the following instructions are added.
comObject=CreateObject("comServer.comObject")
returnValue=comObject.DoWork(.......)
...
comObject = Nothing
However, when processing two different http requests at the same time, the latter one seems to overwrite the first request, giving the first requester an error. It looks as if the comObject variable is shared between the requests.
How to instantiate the object in such a way that every separate request in IIS, gets it's own instance of the comObject?
Without knowing what the object does or how it does it, it's impossible to give specific advice. A general description will have to do:
The object is broken/buggy. It is the object's responsibility to handle the problem.
A COM object is supposed to handle all threading issues internally, or defer to COM STA apartments if it cannot do it, or doesn't want to (for those aspects that an STA can handle). This goes deep into the design of the object.
Regardless of COM Apartment choice, a DoWork(...) method with a semantic that precludes multiple separate COM objects in separate threads from handling simultaneous calls - is a seriously problematic design at best. A proper design would either include mechanisms to handle the conflict explicitly, or just hide the conflict from the calling code and handle the conflict internally.
Depending on the details of what DoWork() does, there might be ways to fix the object in such a way that the calls can succeed in parallel, or block each other so the calls are effectively serialized, or to cause the second call to throw a "You already called me" error. Again, which approach is more appropriate depends heavily on what the method does.
If you can't modify this broken component, your best option would be to write a COM wrapper that ensures serialization to the real object.
In any case, there is nothing reasonable you can do from the client (ASP VBScript) side.
I have several client GUI windows all derived from QMainWindow. Each window is potentially doing a different task but all are requesting data from a central cache implemented as a QThread.
All the clients connect to the same slot in the data cache and then emit signals to prompt the data cache to do something. The signals to the data cache get queued so the data cache only ever does one thing at a time.
When the data cache completes it needs to inform the correct client that the thing it was doing has completed. My immediate thought is to emit a signal to the requesting client about the completion. This would mean connecting to a specific client's slot and then emitting a signal to it.
Do I have to do connect and then disconnect to the client? I'm aware of the QObject::sender() function to get the supplier. Is there some way of emitting a signal to that sender (client) only? Or is there some other way of doing this?
There may be simpler approaches you can take to resolve your problem. For example, I would consider looking into the QtConcurrent framework. Alternately, you might also re-architect your design such that the client first connects to a "finished" signal on the cache prior to asking the cache to do anything. Failing all of that, you might also consider relying on the QMetaObject::invokeMethod function (for either your client or your cache). This function allows you to call an arbitrary method on an arbitrary QObject (provided that you have a pointer to it) using arbitrary generic arguments (in a way that's thread-safe).
If you use the QMetaObject::invokeMethod approach, there are a few of drawbacks you should be aware of. Firstly, you have to invoke the method using its string name, which means that you won't find out at compile time if you're using the wrong name. Secondly, since your clients have a different thread affinity than the central cache, there's a chance that the client will have been destroyed when the cache invokes the method on them (though perhaps in your case, this won't be a problem for you). Finally, you may not want your cache to have any knowledge of the names of the methods that it must execute on its client.
I don't have any way of getting around the first drawback (I'm not sure if this is going to be handled differently in the upcoming Qt 5.0 release). As far as the second and third problems, I would recommend creating an object that encapsulates a reference to a method -- something like the following:
class MethodReference
{
MethodReference(QObject* object, const QString& methodName);
...
bool invoke(QGenericArgument val0 = QGenericArgument(),
QGenericArgument val1 = QGenericArgument(),
...
QGenericArgument val9 = QGenericArgument());
private:
QPointer<QObject> mObject;
QString mMethod;
};
You would then pass this object to your cache from the client. The cache then calls invoke on this object.
Note the use of QPointer -- this gives you a thread-safe way of checking if your object has been destroyed before you try to invoke a method on it. Since I've done this before, I'll also let you know that versions of Qt prior to 4.8 had a bug in QPointer that would cause a crash in a multi-threaded context. Use a more recent version of Qt if you want to do this.
I hope this was clear.
Can HttpSessionListener throw exceptions?
If yes, to where do they go? In what point is the stack interrupted?
If no, how should I treat exceptions there? Logging?
Can HttpSessionListener throw exceptions?
The interface itself doesn't throw anything. It's only your own code in the concrete implementation which can do that.
If yes, to where do they go? In what point is the stack interrupted?
The container catches it, logs it to the server log, ignores the failed call and then continues the job it is supposed to do.
If no, how should I treat exceptions there? Logging?
Write robust code so that you've eliminated all code bugs (which may cause RuntimeExceptions). Put if necessary a try-catch around uncontrollable exception-sensitive code in the implementation yourself so that you can handle it yourself on whatever sensible manner you think you need to handle it.
HttpSessionListener is an interface, so the answers to your questions will depend upon your implementation. If your implementation can throw an Exception, you should at least log it. If you need to display something to the user, you could stick something in the session and then have a javax.servlet.Filter look for that key, etc.
I'm working on implementing communication between an Adobe AIR app and a browser Flash object, and the LocalConnection documentation mentions an asyncError as a potential event:
asyncError: Dispatched when an exception is thrown asynchronously — that is, from native asynchronous code.
However, that's the only documentation I can find on it. Does anyone know what this error actually means? I've searched around but couldn't find any reference -- most sample code I found does an addEventListener() for the asyncError but doesn't give any clue as to what it means or when it could occur (i.e. if it could occur when sending or when recieving).
The Adobe documentation page also lists potential events for each method, but asyncError isn't listed under any specific method, only for the general class.
Has anyone ever had an asyncError occur?
Thanks!
This error is also dispatched from NetConnection. In that case it's used as expected: to handle errors thrown asynchronously by the connection. In the handler for the NetConnection if you do something like:
trace(event.text);
You will get something back like:
Error #2095: flash.net.NetStream was unable to invoke callback onMetaData.
You can use the same technique to figure out why the LocalConnection is throwing this error and handle it according to the message.