*i want to know that what happen when validity time expire, some think that know is change state IDLE and remove from session, but what kind of request we send to client *
The Tcc timer supervises an ongoing credit-control session in the
credit-control server. It is RECOMMENDED to use the Validity-Time
as input to set the Tcc timer value. In case of transient failures in the network, the Diameter credit-control server might change to Idle state. To avoid this, the Tcc timer MAY be set so that Tcc equals to 2 x Validity-Time. in case of the timers expire diameter need to send a notification to connected devices that this session is no longer active so delete info about this session. Diameter send Session Termination Request and delete all related data if this session, also from the database.
Related
When I launch Jupyter lab session it is not logging me off .I observed that the inactive session timeout for the web application is not adequate. After testing for about one hour, I concluded that the inactive session timeout was either not configured or longer than 1 hour. I want to set session timeout for this problem, So that session must logoff when user is away for a longer period of time.
1-What is the name of that file?
2-where the file is located?
3-what parameters need to change to resolve (No session timeout).
Kindly provide answer.
I am using Azure service bus topic/subscriptions with sessions.
I am setting a hardcoded value for the sessionId as I want to control processing of incoming messages.
So even if there are more than one eligible subscribers which can process this message only one will get the sessionlock and process it. I release the lock by closing the session once it is done processing so that new messages can be picked up by any of the processors. My only concern here is, is there any downside of closing the session after completion of message processing?If I close session, will the processor with closed session be able to open session and process the message at later?
TIA
Sessions are usually intended for groups of messages and not a single message. When you want those messages to be processed in order (FIFO) a single subscriber should handle that subscription until messages in the session are all processed. And then, what you do, closing a session, is fine as it will expire eventually. Not to mention that your subscriber could start processing another session rather than waiting for an "empty" session to time out.
In case you have a single message per session, I would advise against using sessions to begin with.
I need clarification on "Credit-Control-Failure-Handling" AVP, and I'd be appreciated if someone can explain about its enumerated values.
So, as I understand if CCFH is in TERMINATE mode (0), and the client doesn't receive CCA within Tx timer period, then the request is regarded as failed and basically session will be terminated.
However, if CCFH is in CONTINUE mode (1), quoted from RFC4006:
When the Credit-Control-Failure-Handling AVP is set to CONTINUE,
the credit-control client SHOULD re-send the request to an
alternative server in the case of transport or temporary failures,
provided that a failover procedure is supported in the credit-
control server and the credit-control client, and that an
alternative server is available. Otherwise, the service SHOULD be
granted, even if credit-control messages can't be delivered.
So, my understanding is unlike TERMINATE mode, if the CCA does not answer within Tx timer, the client would provide the service to the end-user.
My question is what if the server actually sends a CCA error message like (DIAMETER_TOO_BUSY or other error messages) within Tx timer to the client. Is the client still provide the service to the end-user or not?
TERMINATE is exactly to terminate.
Later on same doc (or actually - its newer version 8506) says:
When the Tx timer expires, the Diameter Credit-Control client always
terminates the service if the CCFH is set to the value TERMINATE.
The credit-control session may be moved to an alternative server only
if a protocol error DIAMETER_TOO_BUSY or DIAMETER_UNABLE_TO_DELIVER
is received before the Tx timer expires. Therefore, the value
TERMINATE is not appropriate if proper failover behavior is desired.
I want to know how to handle qldb sessions in a node.js application.
Should I create one session for the entire scope of the app or should I make a new session before each batch of transactions?
Right now I'm creating a session before each transaction and I'm getting some OCC conflicts when running unit tests (for each test a new session is created).
You should use as many sessions as needed to achieve the level of throughput required. Each session can run a single transaction, and each transaction has a certain latency. So, for example, if your transactions take 10ms, then you can do 100 transactions per second (1s = 1000ms and 1000/10 = 100). If you need to achieve 1000 TPS, you would then need 10 sessions.
The driver comes with a "pool" of sessions. So, each transaction should request a session from the pool. The pool will grow/shrink as required.
Each session can live no longer than ~15 minutes (there is some jitter). Thus, you should handle the case where using a session throws an exception (invalid session) and retry your operation (get a session, run the transaction).
In terms of OCC, I think that is quite likely unrelated to your usage of sessions. OCC means you read data in your transaction that was changed by the time you tried to commit. Usually this means you haven't setup the right indexes, so your reads are scanning all items in a table.
CCFH - Do a CCR message set the T bit during failover ?
Scenario
I have a client and 2 OCS servers.
I didnt get the CCA response (CCA -I ) from first OCS.
After my TX timer expiry I am retransmitting CCR I to second OCS.
Question here is -
Do the retransmitted CCR needs the T bit to be set ?
In RFC I cannot see this specifically mentioned anywhere
You can find the answer in the RFC 4006 Diameter Credit-Control Application
If the timer Tx expires, the credit-control client MUST continue the
service and wait for a possible late answer. If the request times
out, the credit-control client re-transmits the request (marked with
T-flag) to a backup credit-control server, if possible. If the re-
transmitted request also times out, or if a temporary error is
received in answer, the credit-control client buffers the request if
the value of the Direct-Debiting-Failure-Handling AVP is set to
TERMINATE_OR_BUFFER.