It is in the news that HP scientists is getting close to be able to produce devices based on memory resistors. One of them, Stan Williams, claims that we will see devices based on memory resistors working better than current NAND based devices in three years.
This is the beginning of a revolution. Besides the fact that memory resistors may potentially be used as more than just storage devices, fast static memory will change how computer software operate.
Currently, all application software, even including operating system and hardware drivers, follow a "load - execute - store" model. Data is loaded from permanent storage into RAM, processed, and then stored back to permanent storage. Faster static memory will make this model obsolete. A new model should be a "go to - execute" model. Nothing needs to be loaded. Software can execute exactly where it is stored because there will be no such thing as RAM anymore. Results need not be stored, because the results are already stored where they are in memory!
Because so much of our current software manage the load - store process of data, a new generation of software simply using "go to" without load/store will be needed to efficiently utilize the new hardware. All OS's, such as UNIX, LINUX, and Windows will all need to be re-written. After that, we will look back at the current "load - store" model software age as the "stone age".
Of course, some moving around of data will still be necessary from time to time, and data access to slow legacy storage will still need to follow the old model, at least partially. But that is different from the way things are now because to the new computers, connections to these devices will be treated almost like the way current computers handle phone dial-up modem connections. These devices can be "memory-mapped", but they are essentially "shadowed" with local static memory. So the loading process become a "shadowing process".
Monday, April 12, 2010
Wednesday, April 7, 2010
WCF with MSMQ
WCF over MSMQ can be difficult to setup. There are just too many layers. Frankly, in my opinion, it would be easier to implement fail over mechanisms without so may layers. Without all these extra layers, the chances of failures would be reduced, and the need for fail over is smaller at the first place.
When MSMQ throws an exception, the WCF host goes into a faulted state. You must handle the "Faulted" event of the service host in order to get any information on the fault. Without such an event handler, the service host just sits there quietly, as if there is nothing wrong. It will not handle any messages, and it will not give you any indication whatsoever that something is wrong.
Even if you do handle this event, there is little can be learned other than the service host entered faulted state. If you are lucky and you are in a debugger, you will see the exception that MSMQ threw, otherwise there is no way to retrieve the exception, especially if the service host runs in a service application.
One common MSMQ exception is that "An error occurred while receiving a message from the queue: The transaction specified cannot be imported. (-1072824242, 0xc00e004e). Ensure that MSMQ is installed and running. Make sure the queue is available to receive from." The error code is MQ_ERROR_TRANSACTION_IMPORT (0xC00E004E), which typically means that the transaction coordinator is not available. It turns out that you would have to allow MSDTC on the service host machine to access the network if the queue is not local.
Turning on network access for MSDTC requires the use of some tools. They are hidden at some not-so-obvious places: you would have to run dcomcnfg, open "Component Services". In some versions of Windows "Component Services" is on the "Administrative Tools" menu, but in some other versions, it is not.
Once you have found "Component Services", you need to go to the properties dialog box of "My Computer". On the "MSDTC" tab, check "Use local coordinator".
We are not done. Under "My Computer" in "Component Services", go to "Distributed Transaction Coordinator", "Local DTC", and go to its properties dialog box. Go to the security tab, and check "Network DTC Access".
All this is too complicated to maintain for a simple WCF service, not to mention the security implications. If you really love MSMQ so much that you have to have it, then this would get it to work. But WCF can work with simpler protocols. These simpler protocols are more reliable and more secure. After all, what MSMQ does is simple, we can live without it.
When MSMQ throws an exception, the WCF host goes into a faulted state. You must handle the "Faulted" event of the service host in order to get any information on the fault. Without such an event handler, the service host just sits there quietly, as if there is nothing wrong. It will not handle any messages, and it will not give you any indication whatsoever that something is wrong.
Even if you do handle this event, there is little can be learned other than the service host entered faulted state. If you are lucky and you are in a debugger, you will see the exception that MSMQ threw, otherwise there is no way to retrieve the exception, especially if the service host runs in a service application.
One common MSMQ exception is that "An error occurred while receiving a message from the queue: The transaction specified cannot be imported. (-1072824242, 0xc00e004e). Ensure that MSMQ is installed and running. Make sure the queue is available to receive from." The error code is MQ_ERROR_TRANSACTION_IMPORT (0xC00E004E), which typically means that the transaction coordinator is not available. It turns out that you would have to allow MSDTC on the service host machine to access the network if the queue is not local.
Turning on network access for MSDTC requires the use of some tools. They are hidden at some not-so-obvious places: you would have to run dcomcnfg, open "Component Services". In some versions of Windows "Component Services" is on the "Administrative Tools" menu, but in some other versions, it is not.
Once you have found "Component Services", you need to go to the properties dialog box of "My Computer". On the "MSDTC" tab, check "Use local coordinator".
We are not done. Under "My Computer" in "Component Services", go to "Distributed Transaction Coordinator", "Local DTC", and go to its properties dialog box. Go to the security tab, and check "Network DTC Access".
All this is too complicated to maintain for a simple WCF service, not to mention the security implications. If you really love MSMQ so much that you have to have it, then this would get it to work. But WCF can work with simpler protocols. These simpler protocols are more reliable and more secure. After all, what MSMQ does is simple, we can live without it.
Subscribe to:
Posts (Atom)