I have a waveform used to demodulate a signal received on an RTL device. Someone else created the waveform using REDHAWK 1.8.3 and it works fine for him. I am running REDHAWK 1.9 in a CentOS 6.3 virtual machine. I have reconfigured and rebuilt everything. When that did not work, I regenerated everything for 1.9 and rebuilt again and had the same result. I am able start the domain manager and device manager without error. When I try to instantiate an instance of the waveform, I get the following:
WARNING: Unable to set bandwidth.
INFO:RTLRDC_i - Allocated [FRONTEND::tuner_allocation] RX_DIGITIZER_CHANNELIZER, 0 to MC_Frontend
ERROR:PropertySet_impl - Setting property control failed. Cause: Unable to set value
ERROR:ApplicationFactory_impl - Failed to 'configure' component: 'MultiDemod' with component id: 'MultiDemod_1:MCWaveform_1 assigned to device: 'DCE:539804f4-37cc-426f-8dd0-3128d866981e' in waveform 'MCWaveform_1';InvalidConfiguration with this info: <No matching properties found> for these invalid properties: (control,Kind: 21) error occurred near line:3251 in file:ApplicationFactory_impl.cpp;
INFO:RTLRDC_i - Deallocated [FRONTEND::tuner_allocation] RX_DIGITIZER_CHANNELIZER, 0 for MC_Frontend
ERROR:ApplicationFactory_impl - Error in application creation; Configure of component failed (unclear where in the process this occurred)
The 'control' property does exist on the component. Does anyone have any thoughts on what the issue could be?
The control property is a struct. One of the fields in the struct did not have an initial value set. This was not an issue for REDHAWK 1.8.3 but caused the above error for REDHAWK 1.9. The solution was to make sure that all parameters for the struct had an initial value.
Related
We are getting following below error when we deploy any application in Liferay DXP 7.
When we clean the Liferay DXP and then redeploy the below issue gets fixed.
But the problem with this approach is that all the caches gets deleted after cleaning and when we redeploy and access the site , the caches gets recreated but it takes lot of time to access any page on the site.
[2018-05-17 10:58:33,113] [DEBUG] [10.111.2.74] [] [http-nio-5443-exec-8] [com.fsvps.clientPortal.service.common.ProgramFilterPopulator] - Retrieving logged in user
[2018-05-17 10:58:33,137] [DEBUG] [10.111.2.74] [] [http-nio-5443-exec-8] [com.fsvps.clientPortal.util.common.UserContextInitializationInterceptor] - Portlet mode view and debug mode = false
[2018-05-17 10:58:33,137] [DEBUG] [10.111.2.74] [] [http-nio-5443-exec-8] [com.fsvps.clientPortal.util.common.UserContextInitializationInterceptor] - Checking to see if invalid filter view should be shown
[2018-05-17 11:07:40,859] [DEBUG] [] [] [http-nio-5443-exec-2] [com.fsvps.clientPortal.util.common.UserContextInitializationInterceptor] - Entering
[2018-05-17 11:07:40,859] [WARN] [] [] [http-nio-5443-exec-2] [org.springframework.web.portlet.DispatcherPortlet] - Handler execution resulted in exception - forwarding to resolved error view
java.lang.ClassCastException: com.fsvps.clientPortal.domain.common.UserContext cannot be cast to com.fsvps.clientPortal.domain.common.UserContext
at com.fsvps.clientPortal.domain.common.UserContext$$FastClassBySpringCGLIB$$818d2483.invoke(<generated>)
at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:738)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:133)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:121)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:673)
at com.fsvps.clientPortal.domain.common.UserContext$$EnhancerBySpringCGLIB$$830ac420.setIpAddress(<generated>)
at com.fsvps.clientPortal.util.common.UserContextInitializationInterceptor.preHandle(UserContextInitializationInterceptor.java:93)
at org.springframework.web.portlet.handler.HandlerInterceptorAdapter.preHandleRender(HandlerInterceptorAdapter.java:72)
at org.springframework.web.portlet.DispatcherPortlet.doRenderService(DispatcherPortlet.java:739)
at org.springframework.web.portlet.FrameworkPortlet.processRequest(FrameworkPortlet.java:537)
The exact cause is impossible to pinpoint with the information you give. However, the class of problem is easy to identify:
java.lang.ClassCastException:
com.fsvps.clientPortal.domain.common.UserContext cannot be cast to
com.fsvps.clientPortal.domain.common.UserContext
(separated to lines to illustrate the identical class name)
Whenever a class can't be typecasted to itself or a legitimate superclass/interface, you're dealing with duplicate code: There are two versions of the class with the same name available to the classloader, and the system is choosing both.
As the error message just contains the name of the class, not its classloader, a first glance at the error message doesn't make sense. Knowing that a class is uniquely described by its package, name, and its classloader leads you to the root cause.
Identify your modules and make sure that there's only one option for com.fsvps.clientPortal.domain.common.UserContext available.
Edit: Answering to your comments - without knowing your deployment details, there's no way to help you other than wild guesses. Please add more information to your question if the next wild guess doesn't help:
The name of the class, UserContext, suggests that you might store it somewhere, e.g. in a session. Doing so will prevent the original class from unloading when you're undeploying your plugin. Note that there is a huge difference between undeploying code and garbage collecting objects: GC can only happen, when there is no more reference.
If you deploy an updated version of your plugin, the old and existing objects still are referencing the previously loaded UserContext class, while the new code is trying to assign it to a new UserContext reference. Even though, both might be identical in implementation, they are different classes that just share the name.
You can't keep long living references to code that might undeploy, and expect them to stay usable. A quick fix (if you're deploying OSGi modules) might be to extract stable and long-used classes into its own bundle that you won't redeploy. Or replace session stored objects (assuming that this is it) with Java runtime classes, e.g. Map of built-in types, and build a UserContext object from those types whenever you need it.
I'm using the Redhawk IDE 2.0.1 in Centos 6.5.
If I generate a Python based FEI, install, run, allocate, and then try to change the center_frequency via the Properties tab in the IDE I get the error:
Failed to update device property: Center Frequency
Error while executing callable. Caused by org.omg.CORBA.NO_IMPLEMENT: Server-side Exception: null vmcid: 0x41540000 minor code: 99 completed: No
Server-side Exception: null
I've tried to totally different systems and I get the same behavior.
If I do the same thing with the C++ project it works fine. Seems to me the auto generated Python code in 2.0.1 is broken like maybe it's not registering the listener? Any ideas are appreciated as this app will be much easier to implement in Python for me. Thanks
The error org.omg.CORBA.NO_IMPLEMENT: Server-side Exception is a CORBA exception indicating that the FEI device does not implement the setTunerCenterFrequency method, despite the FEI device having a DigitalTuner port. The DigitalTuner IDL inherits from the AnalogTuner IDL, which provides the setTunerCenterFrequency method. There must be a bug in the implementation of the FEI DigitalTuner port. In ${OSSIEHOME}/lib/python/frontend/input_ports.py, InDigitalTunerPort does not inherit from the InAnalogTunerPort, which is where the setCenterFrequency method lives. Changing it to the following should fix this issue:
class InDigitalTunerPort(FRONTEND__POA.DigitalTuner, InAnalogTunerPort):
def __init__(self, name, parent=digital_tuner_delegation()):
InAnalogTunerPort.__init__(self, name, parent)
There's a second issue as well. The generated base class instantiates the DigitalTuner port without passing in a reference to itself, the parent. The generated base class of your FEI Device should change from this:
self.port_DigitalTuner_in = frontend.InDigitalTunerPort("DigitalTuner_in")
to this:
self.port_DigitalTuner_in = frontend.InDigitalTunerPort("DigitalTuner_in", self)
I'm using RedHawk 1.10.0 on CentOS 6.5_x64.
I installed UHD 3.7.2.0 in order to try to employ USRP, B100 0r USRP1, both linked by usb connection, on this fantastic framework!
I built new node using GPP and USRP_UHD device and everything seems going well(GPP and USRP_UHD status are STARTED).
Therefore I tried to allocate FrontEnd Tuner from DeviceManager>USRP_UHD>FrontEnd Tuner>Allocate.
After I filled every fields and I pushed Finish.
Every parameter referred to USRP is correct, except for Your Allocation ID in which I have some doubts.
I got this message on my screen:
'The allocation request was not accepted because resources matching all aspects of the request were not available'
and I got this message on the console(level of console debug:TRACE):
2014-09-05 17:10:39 TRACE FrontendTunerDevice:369 - CORBA::Boolean frontend::FrontendTunerDevice<TunerStatusStructType>::allocateCapacity(const CF::Properties&) [with TunerStatusStructType = frontend_tuner_status_struct_struct]
2014-09-05 17:10:39 INFO FrontendTunerDevice:502 - allocateCapacity: NO AVAILABLE TUNER. Make sure that the device has an initialized frontend_tuner_status
2014-09-05 17:10:39 TRACE FrontendTunerDevice:578 - void frontend::FrontendTunerDevice<TunerStatusStructType>::deallocateCapacity(const CF::Properties&) [with TunerStatusStructType = frontend_tuner_status_struct_struct]
2014-09-05 17:10:39 DEBUG FrontendTunerDevice:603 - ALLOCATION_ID NOT FOUND: [dspcola:f096df16-0179-478a-a539-6605a96c17b9]
2014-09-05 17:10:39 DEBUG FrontendTunerDevice:637 - ERROR WHEN DEALLOCATING. SKIPPING...
Can some good man help me?
Thanks
I am using Redhawk 1.9. I create a Redhawk Device, Component, Node, and Waveform with default settings. I use C++ implementation on all the above. The problem is that the device can't be allocated since it is not an executable device. In the implementation tab in the code section the "type" variable is set to "Executable" (default value). If this is incorrect then what should it be?
Note: When I make an Device derived from executable device then the problem goes away.
I was able to reproduce the problem with dummy device and component as shown below:
I update the Component so that it will use the device.
<usesdevice id="dummy_device_2" type="usesdevice">
<propertyref refid="DCE:cdc5ee18-7ceb-4ae6-bf4c-31f983179b4d" value="dummy_device_kind_1"/>
</usesdevice>
I update the device properties:
<simple id="DCE:cdc5ee18-7ceb-4ae6-bf4c-31f983179b4d" mode="readonly" name="device_kind" type="string">
<description>This specifies the device kind</description>
<value>dummy_device_kind_1</value>
<kind kindtype="configure"/>
<kind kindtype="allocation"/>
<action type="eq"/>
</simple>
I add the Dummy device created here into the dummy node created here.
I add the Dummy Component to the Dummy Waveform.
I launched the Dummy node that only contains the dummy device
I launched the Dummy waveform that only contains the above dummy device.
I get the following error message:
Failed to create application:
DeviceOnlyTestWaveform_343_114533234 The
following CORBA exception occurred: InvalidCapacity while creating the
application IDL:CF/ApplicationFactory/CreateApplicationError:1.0*
The Domain Manager (run with Trace logging) shows the following:
DEBUG:ApplicationFactory_impl - Trying to find the device
TRACE:ApplicationFactory_impl - Searching for a place to deploy component amongst 1 devices
TRACE:ApplicationFactory_impl - Checking Device DummyNode:DeviceOnlyTesTDevice_1
TRACE:ApplicationFactory_impl - Device DummyNode:DeviceOnlyTesTDevice_1 is loadable
TRACE:ApplicationFactory_impl - Device DummyNode:DeviceOnlyTesTDevice_1 is not loadable
TRACE:ApplicationFactory_impl - Done checking all the devices
DEBUG:ApplicationFactory_impl - Device Allocation Failed.. need to clean up
In ApplicationFactory_impl the code appear to show that the allocation fails since the device is not derived from Executable Device. The code section has "type" to Executable (default setting). If this is not correct then what should it be?
// Check that the device meet's the needs of this component
// - Validate the type of device meets the requirements in the 'code' section of the implementation
//
LOG_TRACE(ApplicationFactory_impl, "Checking Device " << deviceNodeIter->identifier);
if (deviceNodeIter->device->usageState() == CF::Device::BUSY)
{
LOG_TRACE(ApplicationFactory_impl, "Ignoring Device " <<deviceNodeIter->label << " is BUSY");
continue;
}
if ((implementation->getCodeType() == CF::LoadableDevice::EXECUTABLE) ||
(implementation->getCodeType() == CF::LoadableDevice::SHARED_LIBRARY)) {
// Does this device provide LoadableDevice?
LOG_TRACE(ApplicationFactory_impl, "Device " << deviceNodeIter->identifier << " is loadable");
CF::LoadableDevice_var loaddev;
loaddev = ossie::corba::_narrowSafe<CF::LoadableDevice> (deviceNodeIter->device);
if(CORBA::is_nil(loaddev)) {
LOG_TRACE(ApplicationFactory_impl, "Device " << deviceNodeIter->identifier << " is not loadable");
continue;
}
if (implementation->getEntryPoint().size() != 0) {
// Does this device provide ExecutableDevice?
LOG_TRACE(ApplicationFactory_impl, "Device " << deviceNodeIter->identifier << " is executable");
CF::ExecutableDevice_var execdev;
execdev = ossie::corba::_narrowSafe<CF::ExecutableDevice> (deviceNodeIter->device);
if(CORBA::is_nil(execdev)) {
LOG_INFO(ApplicationFactory_impl, "Device " << deviceNodeIter->identifier << " is not executable");
continue;
}
}
}
Although your device is capable of satisfying the usesdevice allocation, without a GPP or other ExecutableDevice, there is no place to run your component. There are two ways that allocation is performed when launching components:
Satisfying usesdevice relationships
Deciding on which device to deploy the executable
Each implementation in the component's SPD has a list of dependencies that must be satisfied to run the entry point. Typically, for a C++ component, this will include the OS and processor type. Additional requirements can be defined based on the processing requirements of the component, such as memory or load average; these must be allocation properties known to the target device, just like with usesdevice. There is also an implicit requirement that the device selected for deployment should support the ExecutableDevice interface (there is slightly more nuance to it, but that's by far the most common case).
When launching a waveform, the ApplicationFactory tries to allocate all required devices and select an implementation for each component in sequence. Each possible implementation is checked against all of the devices in the domain to see if there is a device that meets its dependencies. If so, the entry point for that implementation will be loaded onto the device and executed, and the ApplicationFactory moves on to the next component. If no suitable device can be found, it throws a CreateApplicationError, as you are seeing.
For most cases, you can use the GPP device included with REDHAWK to support the execution of your components. You would usually only write your own ExecutableDevice if you have a specific type of hardware that does not work with GPP, like an FPGA. If you have installed from RPM, there should be a node tailored to your local system (e.g., processor type, Java and Python versions) in your $SDRROOT/dev/nodes directory. Otherwise you can create it yourself with the 'nodeconfig.py' script included with the GPP project; see the Ubuntu installation guide for an example (admittedly, somewhat buried in the REDHAWK Manual, Appendix E, Section 5).
I believe the problem is that you don't have a GPP in the node with your Dummy Device. Because your original Device was not Executable, it was unable to execute the Component's code, which is what the GPP would do for you.
To add the GPP in the IDE, simply open up the DeviceManager.dcd.xml file of your Node, navigate to the Devices tab, and click the Add button. If everything is installed correctly, you should be able to select the GPP, then click Finish. Finally, save the Node and drag it to Target SDR and try launching it with nodeBooter again.
Also, the type "Executable" in the *.spd.xml file isn't specific to Devices. If you look at the implementation section for a Component, you'll notice there is a Type drop down under the Code section as well. The reason for this is because it isn't describing the type of Device/Component, but how the output of the build process should be interpreted.
WHen I start VS2012 I always get an exception tellng me to look at ActivityLog.xml. Here is what I see- useless to me. Hoping someone else has seen this before.
Also - VS2012 eats 100% of the CPU on the machine at time. Hoping the two are related and fixable.
System.ComponentModel.Composition.CompositionException: The composition produced a single composition error. The root cause is provided below. Review the CompositionException.Errors property for more detailed information.
1) The current type, SquaredInfinity.Foundation.Configuration.Services.IConfigurationService, is an interface and cannot be constructed. Are you missing a type mapping?
Resulting in: Resolution of the dependency failed, type = "SquaredInfinity.Foundation.Configuration.Services.IConfigurationService", name = "(none)".
Exception occurred while: while resolving.
Exception is: InvalidOperationException - The current type, SquaredInfinity.Foundation.Configuration.Services.IConfigurationService, is an interface and cannot be constructed. Are you missing a type mapping?
-----------------------------------------------
At the time of the exception, the container was:
Resolving SquaredInfinity.Foundation.Configuration.Services.IConfigurationService,(none)
Resulting in: An exception occurred while trying to create an instance of type '#Btb.#Rtb'.
Resulting in: Cannot activate part '#Btb.#Rtb'.
Element: #Btb.#Rtb --> #Btb.#Rtb
Resulting in: Cannot get export '#Btb.#Rtb (ContractName="Microsoft.VisualStudio.Text.Classification.IClassifierProvider")' from part '#Btb.#Rtb'.
Element: #Btb.#Rtb (ContractName="Microsoft.VisualStudio.Text.Classification.IClassifierProvider") --> #Btb.#Rtb
at System.ComponentModel.Composition.Hosting.CompositionServices.GetExportedValueFromComposedPart(ImportEngine engine, ComposablePart part, ExportDefinition definition)
at System.ComponentModel.Composition.Hosting.CatalogExportProvider.GetExportedValue(CatalogPart part, ExportDefinition export, Boolean isSharedPart)
at System.ComponentModel.Composition.Hosting.CatalogExportProvider.CatalogExport.GetExportedValueCore()
at System.ComponentModel.Composition.Primitives.Export.get_Value()
at System.ComponentModel.Composition.ExportServices.GetCastedExportedValue[T](Export export)
at System.ComponentModel.Composition.ExportServices.<>c__DisplayClass42.<CreateStronglyTypedLazyOfTM>b__1()
at System.Lazy1.CreateValue()
at System.Lazy1.LazyInitValue()
at System.Lazy1.get_Value()
at Microsoft.VisualStudio.Text.Utilities.GuardedOperations.InvokeMatchingFactories[TExtensionInstance,TExtensionFactory,TMetadataView](IEnumerable1 lazyFactories, Func2 getter, IContentType dataContentType, Object errorSource)
Is your VSCommands extension up to date?
There was a compatibility issue which could produce similar stack trace, and it was fixed in latest release.