I have noticed in wrapper.conf file, that there is a gap in java.additional. properties:
wrapper.java.additional.5=-Dorg.glassfish.grizzly.nio.transport.TCPNIOTransport.max-receive-buffer-size=1048576
wrapper.java.additional.6=-Dorg.glassfish.grizzly.nio.transport.TCPNIOTransport.max-send-buffer-size=1048576
# Limit the Metaspace Size to protect system memory from unwanted usage
# Increase this value if you get "Java.lang.OutOfMemoryError: Metaspace" error
wrapper.java.additional.8=-XX:MaxMetaspaceSize=256m
Is this OK? I think all additional properties starting from 8 are ignored. Also, when I add new property (18, because last active property in the original file is 17) - it is ignored as well.
Yes, gaps are ok because there is a configuration option in the default wrapper.conf set to accept the gaps:
# Ignore gaps in additional properties sequence
wrapper.ignore_sequence_gaps=TRUE
Ignored options are a symptom of some other problem. Are you running in Windows as a service? There is a known permissions issues about that where auto generated properties override manually set properties: https://help.mulesoft.com/s/article/wrapper-conf-Configuration-is-not-Updated-when-Mule-Runtime-is-running-as-a-Windows-Service
In that case you need to uninstall and reinstall the Mule service.
Related
I am using some offset as I am running 2 nodes in one Virtual machine but looks like some port like (5672,9611,9711) are directly present so I suppose offset wont be applied to this ports and i will have to change it manually to get it work ... is their any way to optimise this so that when I apply offset it will change all the ports automatically in run time and I don't have to worry about to change it manually ?
You can add the offset to every port by adding the following configuration to the deployment.toml
[server]
offset = ""
You can refer the following documentation for more information on this
https://is.docs.wso2.com/en/latest/references/default-ports-of-wso2-products/
In API Platform there exist two different settings where to me it is not clear what the difference is betweem them. This is pagination_items_per_page and pagination_maximum_items_per_page. In the pagination documentation it is extensively explained how you can configure these settings, but not when you should use it.
The default (global) configuration is as follows, as seen in the configuration documentation.
api_platform:
defaults:
# The default number of items per page.
pagination_items_per_page: 30
# The maximum number of items per page.
pagination_maximum_items_per_page: ~
I have also followed this Symfony Casts about the topic of API Platform pagination, and there only the setting of pagination_items_per_page is used. This is suggesting that this setting is probably what you need in most cases.
When you set the pagination_items_per_page, does that not already set how many items will be returned anyways. When do you use pagination_maximum_items_per_page?
As you can see in the source code:
pagination_items_per_page defines the default value of items per page, which can be overriden through the request
pagination_maximum_items_per_page defines an upper bound of that possibly user-supplied value to avoid that the user DOS'es your system by requesting all items
Since there is a setting to allow consumers of the API to change the amount of results via a query parameter, the pagination_maximum_items_per_page makes sense to make sure the user does not enter such a large value that your result is too large for your resources.
To allow pagination to be used as a query parameter globally, use the following configuration:
api_platform:
defaults:
pagination_client_enabled: true
pagination_client_items_per_page: true
I still have the open question whether this is the only situation where you would use the pagination_maximum_items_per_page, or if this setting also prevents a very large pagination setting for a specific resource (with: #ApiResource(attributes={"pagination_items_per_page"=9999}) for example) by overwriting that value if it exceeds the max per page setting.
Dev environment:
Windows 10
Fuse 1.4.0 (build 14778)
This morning I've noticed I'm getting a warning showing up when I build my project:
build\Local\Designer\cache\ux13\ClearButton.g.uno(6.19): W0000: ClearButton.Width hides inherited member Fuse.Elements.Element.Width -- use the 'new' modifier if hiding is intentional
C:\myproject\build\Local\Designer\cache\ux13\ClearButton.g.uno(6,20): Warning W0000: ClearButton.Width hides inherited member Fuse.Elements.Element.Width -- use the 'new' modifier if hiding is intentional(2.0 s)
As far as I can tell, I keep getting this warning even when I reset my code back to its state before the warning was showing up.
Doing uno clean or manually deleting the build folder does not seem to fix the problem either.
The warning originates from the fact that you have created a custom ux:Class with the name ClearButton, and inside of that class you have defined a ux:Property with the name Width.
Since Width is an already existing default property for all visuals that inherit from Fuse.Elements.Element (which is many, if not all) in Fuse, you're essentially hitting a reserved name.
Lucky for you, it's just a warning. It is very likely that you're not experiencing any unwanted side effects, unless you're using the Width property in very exotic ways.
To solve the issue and get rid of the warning, give that property a different name.
we upgraded from HV 4.x to HV 5.4.2 and now when we have interface like following
#NotNull
List<AccountInfo> getMultiClientAccountBalances(#NotNull ClientContext clientContext, #NotNull Optional<AccountFilter> accountFilter);
I'm getting error:
javax.validation.UnexpectedTypeException: HV000186: The constraint of type 'javax.validation.constraints.NotNull' defined on 'getMultiClientAccountBalances.arg1' has multiple matching constraint validators which is due to an additional value handler of type 'org.hibernate.validator.internal.engine.valuehandling.OptionalValueUnwrapper'. It is unclear which value needs validating. Clarify configuration via #UnwrapValidatedValue.
I know it can be fixed by adding #UnwrapValidatedValue to the field, but this must be added to every method what is a lot of work for me. Is there any simpler solution (besides upgrade to HV6.x)
Unfortunately I don't see how we could change this behavior in 5.4 without breaking other use cases.
And there is no easy way to disable the optional value handler as it's added unconditionally.
So I would say you have two solutions:
a search and replace of all #Constraint Optional to add the UnwrapValidatedValue option
or move to HV 6, where we totally reworked this feature and where, I think, it should work as you expect it. I know you didn't want this answer but it is what it is...
The issue with 1. is that we removed this annotation from HV (it was experimental) in favor of a standard feature included in Bean Validation so you will have to remove it when moving to 6.
I don't know your exact environment but HV 6 is highly compatible with the previous versions so it might work very well. Just be careful about the dependencies as we changed the groupId of the artifact from org.hibernate to org.hibernate.validator. Also be aware that you need to update the validation-api from 1.1 to 2.0.
6 is already very stable and if you have any issues with it, we will fix them right away.
in prokb,its mentioned
In 10.0B02 and above, the client session startup parameter -noincrwarn was reintroduced
to allow the selective suppression of the above four warning messages ONLY. Since the
execution of the 4GL statement: SESSION:SUPPRESS-WARNINGS = YES. suppresses ALL warning
messages during the session.
Where and how could i set i this startup parameter -noincrwarn to suppress this warning
message?
"SESSION:SUPPRESS-WARNINGS = YES." doesn't do much of anything useful. Or at least it didn't the last time I tested it.
The -mmax warning is harmless. It is a "soft" limit that is dynamically allocated and expanded as needed. You can ignore it. Or if the .lg file entries really bother you, you can simply increase it to a reasonable value. I routinely set it to 8192 for character sessions, 32768 for Windows. The default, as JensD says, is ludicrously low.
Startup parameters, such as -noincwarn, can set in a number of ways:
1) Via the command line. If your application starts via a script it will eventually invoke progress via "pro", "mpro", progress, prowin32, proapsv or some other executable (you can potentially link your own objects and create custom executables...) The command line that invokes Progress will have a number of parameters. You could add it there. Windows example:
#echo off
set DLC=\Progress\OpenEdge
%DLC%\bin\prowin32 -db mydb -p start.p -noincwarn
(On windows it is also common for the shortcut properties to have the command line listed.)
2) In a "pf" file. "PF" files are parameter files. They contain a list of parameters in a text file. This makes it easy to share and manage parameters between many scripts. To use a parameter file you need at least one -pf filename.pf parameter. Unix example:
#!/bin/sh
DLC=/usr/dlc
export DLC
${DLC}/bin/_progres -db mydb -pf mypf.pf
Where "mypf.pf" might contain:
# mypf.pf
-p start.p
-noincwarn
There is a global .pf file in the Progress install directory called startup.pf. You could also add it to that.
3) In an "ini file". Sort of like the pf file but more complicated. Indicated by the -ininame startup parameter. Can also be influenced by registry keys.
Why not removing or trying another value for -mmax? If you're moving from an old version of Progress it might be that -mmax is set very low.
The Maximum Memory (-mmax) client session parameter specifies the maximum amount of memory allocated for r-code segments, in kilobytes.
Source: http://knowledgebase.progress.com/articles/Article/P11351?popup=true
Large memory consumption might depend on complicated business logic (things like very large and or deeply nested procedures) so you might consider looking into that.
However a much easier fix would be to increase the value. Default is 3096, meaning each client "only" gets 3 Mb for this. Not a very large amount with today's standards.
If you really only want to suppress the message. Set -noincrwarn in your client side startup script (or corresponding .pf-file/startup.pf).
Hosting a WPF element (windows Presentation Foundation) in an OpenEdge application can cause application to crash if any message cover the window. It is also the case of this message.
In order to suppress any messages including message 5409 ()
According to article "HOW TO SUPPRESS WARNING MESSAGES (5407),(5408),(5409),(5410) FROM DISPLAYING ON CLIENT SCREENS."
I used with expected results SESSION:SUPPRESS-WARNINGS = YES. As the first line in the starting procedure of the aplication.
Using -noincrwarn as the session startup parameter had no effect in Open Edge 11.4
Supress openedge messages:
http://knowledgebase.progress.com/articles/Article/P79795?popup=true
.NET related error for OpenEdge-WPF hibrid application "Invisible or disabled control cannot be activated"
https://social.msdn.microsoft.com/Forums/windows/en-US/e8cf6431-2a59-4335-8b36-fc8f35083823/invisible-or-disabled-control-cannot-be-activated?forum=winforms