I launching a 4D method from Wakanda, I have this error :
{
"__ERROR": [
{
"message": "The maximum number of sessions has been reached",
"componentSignature": "dbmg",
"errCode": 1823
}
],
}
I see 4D databases in Wakanda.
I use 4D rest and I have a method name Test_WebService() in 4D side. In Wakanda, I call the method by ds.FA_UNITES.Test_WebService();
FA_UNITES is my table name
method Test_WebService() 4D side is $0:="Hello"
Anyone can help me ?
The "The maximum number of sessions has been reached" error indicates you do not have the appropriate licenses to use 4D Mobile.
I believe 4D Mobile Expansion is required to develop 4D Mobile applications. It grants you two 4D Mobile Client sessions. If you do have 4D Mobile Expansion, please check if it is activated properly.
Related
Summary:
I have created a small Spring Boot application which should consume messages from a Solace instance. In Solace the publisher has maintained a queue which is subscribed to different topics.
I, as consumer, am processing the messages provided in the queue. Depending on the original topic leading to a message in this queue I would like to react differently in my business logic.
Means I need to somehow extract the topic of the message provided via the solace queue.
I have already have checked JMS header/properties, but I found nothing related to topic.
Anyone any idea or had a similar use case?
A workaround which came to my mind was to directly subscribe to all topics and create for every topic a method to consume and react accordingly, but then we would miss the queue features, or?
Actually the Destination and JMSDestination headers should contain the topic that the message was published to.
For example, to test this real quick I created a StackOverflowQueue queue with a topic subscription to the this/is/a/topic topic. And upon publishing a message to this/is/a/topic my consumer, which was listening to the queue, got the topic info in the header.
To quickly test I used the JMS sample here: https://github.com/SolaceSamples/solace-samples-jms/blob/master/src/main/java/com/solace/samples/QueueConsumer.java
Awaiting message...
Message received.
Message Content:
JMSDeliveryMode: 2
JMSDestination: Topic 'this/is/a/topic'
JMSExpiration: 0
JMSPriority: 0
JMSDeliveryCount: 1
JMSTimestamp: 1665667425784
JMSProperties: {JMS_Solace_DeliverToOne:false,JMS_Solace_DeadMsgQueueEligible:false,JMS_Solace_ElidingEligible:false,Solace_JMS_Prop_IS_Reply_Message:false,JMS_Solace_SenderId:Try-Me-Pub/solclientjs/chrome-105.0.0-OSX-10.15.7/3410903749/0001,JMSXDeliveryCount:1}
Destination: Topic 'this/is/a/topic'
SenderId: Try-Me-Pub/solclientjs/chrome-105.0.0-OSX-10.15.7/3410903749/0001
SendTimestamp: 1665667425784 (Thu. Oct. 13 2022 09:23:45.784)
Class Of Service: USER_COS_1
DeliveryMode: PERSISTENT
Message Id: 1
Replication Group Message ID: rmid1:18874-bc0e45b2aa1-00000000-00000001
Binary Attachment: len=12
48 65 6c 6c 6f 20 77 6f 72 6c 64 21 Hello.world!
Note that sample code doesn't use Spring Boot, but that shouldn't make a difference.
I am trying to run a Spring loader. That loader will take the data from the csv file and insert into oracle database. It starts well, after processing some records, i am getting the below error.
'ORA-12516 - TNS:listener could not find available handler with matching protocol stack'
Note : No other jobs were running at that time. Only this job was running.
processes -- 45 (CURRENT_UTILIZATION) -- 51 (MAX_UTILIZATION)
sessions -- 53 (CURRENT_UTILIZATION) -- 61 (MAX_UTILIZATION)
show parameter processes (processes - integer - 300)
show parameter session (sessions - integer - 480)
The thing is, the same batch program is running fine in another server, which has the same set of above configurations.
Since its a new server, anything i am missing in regards to oracle.? Can someone guide.
I'm interested in updating a ServiceNow record via an ActionCard. Updates to records in ServiceNow only accept a PUT. Is there an action type of HttpPUT in lieu of HttpPOST? A POST is simply denied with
The remote endpoint returned an error (HTTP MethodNotAllowed). Please try again later.
Since I'm using Microsoft Teams, I must use the message card format, per their docs:
"However, if you are sending actionable messages via an Office 365 connector, or to a Microsoft Teams connector, you must continue to use the message card format"
110 - "#type": ActionCard
111 name: Set Assignment Group
112 inputs:
113 - "#type": MultichoiceInput
114 id: list
115 title: Chose an assignment group
116 isMultiSelect: false
117 choices:
118 - display: IT Service Desk
119 value: 4546b6fg1r864z10wk42964pnh4bccpq
120 actions:
121 - "#type": HttpPOST
122 name: Save
123 target: https://servicenow_instance.service-now.com/api/now/table/incident/sys_id
124 headers:
125 - name: Authorization
126 value: Basic base64_encoded
127 body: "{'assignment_group': '{{list.value}}'}"
[Updating answer based on new info]
Because this is just a backend call, with no UI, there's no way for the user to know if the call was successful, or even if it was made at all (i.e. they might push again to see). As a result, it really would be better if you handled the PUT internally somewhere. If you want a complex input/output, you could look at a Tab or Task window, but practically speaking, the best is probably just to have the button click go straight back to the Bot as an input, have the Bot make the call, and respond appropriately to the user.
What that means practically is having your card action change from an "Action.Http" to an Action.Submit. You'd want to have the Submit send a payload of some sort (like a "sys_id" or whatever you need for ServiceNow) on the button click, as the example shows (it's just sending "x" in the link). That way, you get the button click "invoke" so to speak, and the info you need to proceed, without need to maintain state specifically in your Bot.
The call will come through as a normal Turn to your Bot (like a normal message), but instead of having a "text" payload on the Activity, it will have a Value with a CommandId (basically an ID to identify the specific button) and whatever you send as the "data".
Your Bot can simply detect that this property is populated, call ServiceNow, and provide the user with an appropriate response like "ServiceNow Ticket Updated" or whatever.
Hope that helps
[Update] In the end this wasn't a Bot interaction at all - see the comments below for more info and solution
I have a job that posts messages onto IBM MQ.
I have configured my logs to write to a file and not console.
yet when I run this job everytime I see a large amount of logs on the console like this
I have just changed ips and company name in the logs but
what is the source of this
why does it come up
and how do I stop this ?
All my messages get posted successfully so from an end user perspective the job is working fine however I'm not able to make out why this comes up on the console?
RcvThread: com.ibm.mq.jmqi.remote.internal.RemoteTCPConnection[qmid=CANNED_DATA,fap=10,peer=naumib3.mydomain.net/112.999.138.25,localport=56857,ssl=SSL_RSA_WITH_NULL_SHA,peerDN="CN=ibmwebspheremqnaumib3, OU=For Intranet Use Only, OU=For Intranet Use Only, O=My Company, L=New York, ST=New York, C=US",issuerDN="CN=VeriSign Class 3 Secure Server CA - G3, OU=Terms of use at https://www.verisign.com/rpa (c)10, OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US"], READ: SSLv3 Application Data, length = 72
main, WRITE: SSLv3 Application Data, length = 68
[Raw write]: length = 73
0000: 17 03 00 00 44 54 53 48 43 00 00 00 30 01 0C 30 ....DTSHC...0..0
0010: 00 00 00 00 00 00 00 00 00 00 00 01 11 03 33 00 ..............3.
0020: 00 00 00 00 01 00 00 00 00 00 00 00 02 00 00 00 ................
0030: 00 00 00 00 00 41 69 2A 27 7E EB 3A 9B 47 4A 02 .....Ai*'..:.GJ.RcvThread: com.ibm.mq.jmqi.remote.internal.RemoteTCPConnection[qmid=CANNED_DATA,fap=10,peer=naumib3.mydomain.net/112.999.138.25,localport=56857,ssl=SSL_RSA_WITH_NULL_SHA,peerDN="CN=ibmwebspheremqnaumib3, OU=For Intranet Use Only, OU=For Intranet Use Only, O=My Company, L=New York, ST=New York, C=US",issuerDN="CN=VeriSign Class 3 Secure Server CA - G3, OU=Terms of use at https://www.verisign.com/rpa (c)10, OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US"], received EOFException: ignored
RcvThread: com.ibm.mq.jmqi.remote.internal.RemoteTCPConnection[qmid=CANNED_DATA,fap=10,peer=naumib3.mydomain.net/112.999.138.25,localport=56857,ssl=SSL_RSA_WITH_NULL_SHA,peerDN="CN=ibmwebspheremqnaumib3, OU=For Intranet Use Only, OU=For Intranet Use Only, O=My Company, L=New York, ST=New York, C=US",issuerDN="CN=VeriSign Class 3 Secure Server CA - G3, OU=Terms of use at https://www.verisign.com/rpa (c)10, OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US"], called closeInternal(false)
RcvThread: com.ibm.mq.jmqi.remote.internal.RemoteTCPConnection[qmid=CANNED_DATA,fap=10,peer=naumib3.mydomain.net/112.999.138.25,localport=56857,ssl=SSL_RSA_WITH_NULL_SHA,peerDN="CN=ibmwebspheremqnaumib3, OU=For Intranet Use Only, OU=For Intranet Use Only, O=My Company, L=New York, ST=New York, C=US",issuerDN="CN=VeriSign Class 3 Secure Server CA - G3, OU=Terms of use at https://www.verisign.com/rpa (c)10, OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US"], SEND SSLv3 ALERT: warning, description = close_notify
The output looks like it might be from some type of debug or diagnostic patch that might be applied to the MQ JMS/Java client you have installed. The RcvThread is the thread used internally to listen on the TCP socket for data from the QM. Do you know of a patch that might be applied to help with TCP connection issues in the past?
You might want to look at the com.ibm.mq.jmqi.jar that is contained in the MQ client you are using to see if there is a difference in the timestamp or anything noted in the manifest file within the jar file itself.
Agree with the previous answere that is not normally the format of any logs that get written by the JMS Client code. Under normal circumstances the only time that logs are written to stdout in two cases:
One the JMS Client log file controlled by
# Name(s) of the log file(s)
# Can be
# * a single pathname
# * a comma-separated list of pathnames (all data is logged to all files)
# Each pathname can be
# * absolute or relative pathname
# * "stderr" or "System.err" to represent the standard error stream
# * "stdout" or "System.out" to represent the standard output stream
com.ibm.msg.client.commonservices.log.outputName=mqjms.log
And what is called JMS Startup trace - a very early tracing system normally only used on request of IBM Service. (this is documented also in the jms.config file).
I have experimented quite a bit with CDN from Azure, and I thought i was home safe after a successful setup using a web-role.
Why the web-role?
Well, I wanted the benefits of compression and caching headers which I was unsuccessful obtaining using normal blob way. And as an added bonus; the case-sensitive constrain was eliminated also.
Enough with the choice of CDN serving; while all content before was served from the same domain, I now serve more or less all "static" content from cdn.cuemon.net. In theory, this should improve performance since browsers parallel can spread content gathering over "multiple" domains compared to one domain only.
Unfortunately this has lead to a decrease in performance which I believe has to do with number of hobs before content is being served (using a tracert command):
C:\Windows\system32>tracert -d cdn.cuemon.net
Tracing route to az162766.vo.msecnd.net [94.245.68.160]
over a maximum of 30 hops:
1 1 ms 1 ms 1 ms 192.168.1.1
2 21 ms 21 ms 21 ms 87.59.99.217
3 30 ms 30 ms 31 ms 62.95.54.124
4 30 ms 29 ms 29 ms 194.68.128.181
5 30 ms 30 ms 30 ms 207.46.42.44
6 83 ms 61 ms 59 ms 207.46.42.7
7 65 ms 65 ms 64 ms 207.46.42.13
8 65 ms 67 ms 74 ms 213.199.152.186
9 65 ms 65 ms 64 ms 94.245.68.160
C:\Windows\system32>tracert cdn.cuemon.net
Tracing route to az162766.vo.msecnd.net [94.245.68.160]
over a maximum of 30 hops:
1 1 ms 1 ms 1 ms 192.168.1.1
2 21 ms 22 ms 20 ms ge-1-1-0-1104.hlgnqu1.dk.ip.tdc.net [87.59.99.217]
3 29 ms 30 ms 30 ms ae1.tg4-peer1.sto.se.ip.tdc.net [62.95.54.124]
4 30 ms 30 ms 29 ms netnod-ix-ge-b-sth-1500.microsoft.com [194.68.128.181]
5 45 ms 45 ms 46 ms ge-3-0-0-0.ams-64cb-1a.ntwk.msn.net [207.46.42.10]
6 87 ms 59 ms 59 ms xe-3-2-0-0.fra-96cbe-1a.ntwk.msn.net [207.46.42.50]
7 68 ms 65 ms 65 ms xe-0-1-0-0.zrh-96cbe-1b.ntwk.msn.net [207.46.42.13]
8 65 ms 70 ms 74 ms 10gigabitethernet5-1.zrh-xmx-edgcom-1b.ntwk.msn.net [213.199.152.186]
9 65 ms 65 ms 65 ms cds29.zrh9.msecn.net [94.245.68.160]
As you can see from the above trace route, all external content is delayed for quite some time.
It is worth noticing, that the Azure service is setup in North Europe and I am settled in Denmark, why this trace route is a bit .. hmm .. over the top?
Another issue might be that the web-role is two extra small instances; I have not found the time yet to try with two small instances, but I know that Microsoft limits the extra small instances to a 5Mb/s WAN where small and above has 100Mb/s.
I am just unsure if this goes for CDN as well.
Anyway - any help and/or explanation is greatly appreciated.
And let me state, that I am very satisfied with the Azure platform - I am just curious in regards to the above mentioned matters.
Update
New tracert without the -d option.
Being inspired by user728584 I have researched and found this article, http://blogs.msdn.com/b/scicoria/archive/2011/03/11/taking-advantage-of-windows-azure-cdn-and-dynamic-pages-in-asp-net-caching-content-from-hosted-services.aspx, which I will investigate further in regards to public cache-control and CDN.
This does not explain the excessive hops count phenomenon, but I hope a skilled network professional can help in casting light to this matter.
Rest assured, that I will keep you posted according to my findings.
Not to state the obvious but I assume you have set the Cache-Control HTTP header to a large number so as your content is not being removed from the CDN Cache and being served from Blob Storage when you did your tracert tests?
There are quite a few edge servers near you so I would expect it to perform better: 'Windows Azure CDN Node Locations' http://msdn.microsoft.com/en-us/library/windowsazure/gg680302.aspx
Maarten Balliauw has a great article on usage and use cases for the CDN (this might help?): http://acloudyplace.com/2012/04/using-the-windows-azure-content-delivery-network/
Not sure if that helps at all, interesting...
Okay, after I'd implemented public caching-control headers, the CDN appears to do what is expected; delivering content from x-number of nodes in the CDN cluster.
The above has the constrain that it is experienced - it is not measured for a concrete validation.
However, this link support my theory: http://msdn.microsoft.com/en-us/wazplatformtrainingcourse_windowsazurecdn_topic3,
The time-to-live (TTL) setting for a blob controls for how long a CDN edge server returns a copy of the cached resource before requesting a fresh copy from its source in blob storage. Once this period expires, a new request will force the CDN server to retrieve the resource again from the original blob, at which point it will cache it again.
Which was my assumed challenge; the CDN referenced resources kept pooling the original blob.
Also, credits must be given to this link also (given by user728584); http://blogs.msdn.com/b/scicoria/archive/2011/03/11/taking-advantage-of-windows-azure-cdn-and-dynamic-pages-in-asp-net-caching-content-from-hosted-services.aspx.
And the final link for now: http://blogs.msdn.com/b/windowsazure/archive/2011/03/18/best-practices-for-the-windows-azure-content-delivery-network.aspx
For ASP.NET pages, the default behavior is to set cache control to private. In this case, the Windows Azure CDN will not cache this content. To override this behavior, use the Response object to change the default cache control settings.
So my conclusion so far for this little puzzle is that you must pay a close attention to your cache-control (which often is set to private for obvious reasons). If you skip the web-role approach, the TTL is per default 72 hours, why you may not never experience what i experienced; hence it will just work out-of-the-box.
Thanks to user728584 for pointing me in the right direction.