Retry count & interval problem

I am Using OSB R4 where My Scenario is i need to place the payloads in to the JMS Queue, and route them to the Endpoint URI webservice if the service is unavailable i need to sent the notification mail and rollback the payload back in to the Queue. My problem is i receiving hundreds of notification mail when the service is down instead of one. I configured the retry count to 1 and retry interval as 15 mins for the business service URI and implemented single thread consumer in work manager. Please help me in this.....

I am Using OSB R4 where My Scenario is i need to place the payloads in to the JMS Queue, and route them to the Endpoint URI webservice if the service is unavailable i need to sent the notification mail and rollback the payload back in to >the Queue. My problem is i receiving hundreds of notification mail when the service is down instead of one.This is a classic case for using OSB SLA alerting instead of doing it in the message pipeline. Configure a sla alert set to trigger when there are 1 or more route errors in an aggrevation interal of 30 mins and set an email alert destination. This will make sure you will get only 1 mail for all errors in that period of 30 minutes.

Similar Messages

Retry count and retry Interval fields in Business service (Http protocol)

Is retry count and retry Interval in OSB business services(Http protocol) defined for retrying the application errors or for communication errors?
Also even if my connection timeout is 0 I get an error response due to communcation issue in abt 2.5 mins.
Please explain.

- There is an explicit configuration on business service called "Retry Application Errors", if enabled application errors will also be retried.
- If timeout is not set on business service then domain level timeout configuration comes into effect which is by default of 180 sec i.e 3 mins.
Hope this helps.

Process transaction retry count retry delay ERROR

Hi
I've an asynchronous process (listening to a channel). The subscription is synchronous (but i also try it whit an asynchronous subscription).
The matter is:
I've a transaction in the process so i can set the retry count to 23 and the retry delay to 3600 sec.
But when i test it i've got a "dramatic" problem. It only retries 6 times and the time between each retry is zero, it automatically retries.
i don`t know what can i do ... some help ?
zanks in advance
Taja

Hi again
the problem is solved.
Recently we have migrated de DB to a new machine. We exported ALL, data, tables, everithing.
All we do to solve the problem is delete the distributed async queues and create them again.
Redeploy and woala ...
it works again, 23 retries with an interval of 3600 sec
i hope this will be useful for someone.
regards
Taja

Validation error on retry count for session bean

Hi,
In our weblogic-ejb-jar.xml we have configured a retry count for a specific method on a local session bean. When I click on 'Browse' to select a specific method, it only shows '*' as a possible value. When we type the method name by hand, it shows a red cross next to the input field with the error 'Cannot find method "exampleMethod()" in the ExampleBean's Local interfaces'.
We use EJB 3.0 and OEPE 12.1.1.0.1 with Eclipse 3.7.2
The weblogic-ejb-jar.xml looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-ejb-jar xmlns="http://xmlns.oracle.com/weblogic/weblogic-ejb-jar"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd http://xmlns.oracle.com/weblogic/weblogic-ejb-jar http://xmlns.oracle.com/weblogic/weblogic-ejb-jar/1.2/weblogic-ejb-jar.xsd">
    <retry-methods-on-rollback>
     <retry-count>3</retry-count>
        <method>
            <ejb-name>ExampleBean</ejb-name>
            <method-intf>Local</method-intf>
            <method-name>exampleMethod</method-name>
       </method>
    </retry-methods-on-rollback>
</weblogic-ejb-jar>The bean looks like this:
@Stateless(mappedName = MappedName.DONNA)
@TransactionAttribute(value = TransactionAttributeType.REQUIRES_NEW)
public class ExampleBean implements Example {
}And the interface:
@Local
public interface Example {
}Does anyone else have this problem?
Thanks.
Pieter

Hi Pieter,
This is a known issue and I will keep you posted on the development.
Thanks for your feedback!
-Ram

Message retry count for the message has been exhausted

Hi,
I am using 'Custom Document Over Internet' with HTTPS as transport protocol. I have set the acknowledgement mode to Sync in order to receive the synchronous response. B2B is able to post the HTTP request successfully and in turn it receives a synchronous response and a MDN message. At the initial stage, after posting the request it shows the state as 'WaitForAck' for request message and for response and MDN messages, the state is completed.
After some time when we check the state of request it is changed to 'Error' with the error message as 'Message retry count for the message has been exhausted'. We have not set the retry count and retry interval and so after retrying for 3 times with an interval of 120 minutes it is showing error state as it is not able to correlate the incoming response to the corresspoding request. We have tried the option of setting the Message id of the request in 'replyToMsgID' parameter of response header and tested the flow. But still I am facing te same issue. Please help me to resolve this issue.

Hi Anuj,
The property mentioned by NandaGopal has already been added in tip.properties file. I sent the B2B logs in debug mode and tip.properties file to your mail id. Please have a look into that. The result of opatch lsinventory command is
Result:
Installed Patch List:
=====================
1) Patch 9234704 applied on Fri Jan 15 16:41:12 GMT 2010
[ Bug fixes: 8870866 9143036 ]
[ This patch overlays patches " 8703410 " ]
[ This patch needs patches " 8703410 " as prerequisites ]
2) Patch 8703410 applied on Thu Jan 07 17:56:08 GMT 2010
Unique Patch ID: 11901808
[ Bug fixes: 7652646 7497854 7664370 8708445 7661101 7007789 6352814 6802446 7665607 7641078 6496457 6013963 8330151 7305413 8619657 7460584 7529893 7458954 7020996 8393885 8210401 6329207 6740403 7126458 6511970 8783577 7379065 7230993 8704965 6774631 7198642 8309511 8392729 7661769 7605518 7479148 6733262 8349002 6736026 7322333 7242500 7239355 8746561 8344645 8451004 7645440 6747966 6369424 6737334 8339176 6774134 7046561 6412124 7210461 7506319 8630406 8235175 7258882 7184318 6453359 7456866 7673646 6043277 7457597 6769895 7193710 8239170 7668247 8404955 8612841 7261965 7132740 7485790 6518386 7305363 6852370 6433256 7673431 6764239 8360048 7501748 7379153 8281019 7498031 8216457 7046574 6875312 6754906 6656289 6417367 7658271 7556011 7000190 6979467 8594506 8691820 6852308 8475848 8518443 7600385 7211208 6732051 8524862 7461051 8263026 7609467 7379161 7672714 6353293 7157229 7594997 7211287 7034069 7563311 6822375 6640935 7359202 6769261 6919593 8601869 6029507 6974391 7139013 7518641 8605719 6817264 7501903 7496014 7576785 8666761 7130151 7322581 5523563 7680097 8508905 7241737 7660780 8480395 7660781 7191994 6924921 7672723 8432093 6800745 8703404 8540335 8507242 8608121 8217566 7481317 6639030 6200414 7529795 7354853 8475867 7376270 7303860 7016005 7678901 7368610 8992520 6881977 6016128 7033061 6397084 7672730 8703410 7709562 6449656 7045589 8508054 6491068 7378745 7643811 7435853 7615836 8707416 6447557 7379042 6940476 7670634 6950383 6764273 6962327 7478322 8546454 7157324 8871403 8862082 7184219 7672744 7164618 7672745 7230184 7576730 7590301 8746541 7261863 8327427 6769430 8295683 7526186 8298731 6414280 6139955 6646997 7692853 8233048 6794296 7457066 8552373 8225241 7706387 7204022 ]
3) Patch 4601861 applied on Fri Nov 14 04:24:08 GMT 2008
[ Bug fixes: 4601861 ]

SMART tests PASS, but my Spin-up Retry Count is in the yellow

I've had my computer for almost three years. AppleCare is on the verge of expiring. I just toook my MacBook in for a trackpad replacement.
I use TechTools Pro for my hardware testing. My computer passes all of its tests, but I notice that the test for the Spin-Up Retry Count on the SMART status of my harddrive is not totally in the red, but in the yellow, and even then its closer to green than to red. My computer still works great. It does slow down and Spinning-wheel-of-death alot when I'm doing alot of high-CPU load tasks, but for the most part, it still works great. Is this Spin-Up Retry Count something I should be concerned with? My other tests report no bad sectors, bad blocks, or anything else wrong.

Back up all data, then uninstall the worthless, time-wasting "TechTool" product according to the developer's instructions. Reboot. Problem solved.
Oh, that made my day. I actually did that, when I found the Unix tool smartmontools. Set it to perform a full check weekly, and email me if SMART check failed. No use seeing that stuff Techtools shows you.

DB adapter retry count value

Hi gurus,
I am using a db adapter for polling options. The option used is 'Delete the row(s) that were read' .
Here the retry count by default is set to unlimited. Is this the recommended one? In normal db adapter options i see the retry count as '4'
the property value seen in composite.xml is shown below
<property name="jca.retry.count" type="xs:int" many="false" override="may">2147483647</property>
Will this lead to any performance issues? Or what could be the correct retry count value?
Please let us know.

Hi,
We have used the polling options using Logical delete vastly in our project and never faced any performance issues with respect to this property value being set to 'unlimited'.
I believe there should not be any performance issues with respect to the 'Delete the row(s) that were read' option as well.
According Oracle documentation:
In the Auto-Retries section, specify the value for auto-retry incase of time out. In case of a connection related fault, the Invoke activity can be automatically retried a limited number of times. You can specify the following values in the fields in this section:
To retry indefinitely, type unlimited in the Attempts field.
Interval is the delay between retries.
Backoff Factor: x allows you to wait for increasing periods of time between retries. 9 attempts with a starting interval of 1 and a back off of 2 leads to retries after 1, 2, 4, 8, 16, 32, 64, 128, and 256 (28) seconds.
Thanks,
Deepak.

Is it possible to set delivery retry time-interval between messages?

Hello!
          I use Wls 8.1.5 and would love to be able to set delivery retry time-interval between message.
          The complete situtaion looks like this.
          We got one queue (queue_A) that retrives alot of messages.
          At queue_A we got a BMT-MDB that consumes all messages (one by one).
          The BMT-MDB is supposed to forward the messages to an other queue (queue_B). (We also do some other things as well)
          But if we can not forward the message to queue_B because of some Exception is thrown, the transaction is Rolledback exactly as we want.
          But when this happens (for eg the server where queue_b resides is down) our BMT-MDB keeps trying to post the message like an enegizer-bunny. It would feel better if it waited for some seconds before it try again.
          We have tried to set play around with RedeliveryDelayOverride="5000" at the queue_B. But if we set to anything bigger then RedeliveryDelayOverride="-1", then other messages is passing throug and also put into "pending". This ended up in out of memory when the load was big.
          So what we would love to be able is to have all messages in a FIFO-row at the queue_A. And if queue_B is out of order then keep on trying consume the firts messagesd for every 5 sec.
          So if any one know if and how to configure a Wls 8.1.5 please let us know!
          Best regards
          Fredrik

Hello Again Fredrik!
          Later versions have several more options, but here are some that might work on 8.1:
          (A) A good bit of coding: Write code that undeploys the MDB on certain failures, and redeploys it sometime later.
          (B) A small amount of coding: On a failure, simply force a tx rollback, then put a Thread.currentThread.sleep() in the MDB application itself. (Just make sure the MDB is setup with a dedicated thread pool to avoid using up default threads.)
          (C) Requires no coding: Have the MDB forward the message to a local destination rather than the remote destination (so the forward always succeeds), then use the messaging bridge to forward the message onward. The messaging bridge automatically does a periodic retry on failure, and doesn't need to use redelivery delays.
          (D) Requires no coding: Raise a support case with BEA - I personally consider the fact that redelivery delay messages fail to page out likely indicates that there's a bug in 8.1. (Upgrade to 9.x quite likely doesn't have this problem.)
          Hope this helps,
          Tom

HELP ! Making a retry counter

I'm making a retry counter for the logins and I'm using the j_security_check from Tomcat.
I made a little class that must check if there is a session object.
if not create one and put the value 1 in it, for the first try.
If there is a session object, increase the value and put it in the session object.
Now is my problem that I get a nullpointer exception and I don't know how to fix it.
This is the code:
package beans;
import java.io.Serializable;
import javax.servlet.http.*;
import javax.servlet.jsp.PageContext;
* @author Sander Stad
public class LoginCountBean implements Serializable{
     private int count;
     private String loginTries = null;
     private Integer logins;
     HttpSession session;
     HttpServletRequest request;
     PageContext pageContext;
     public LoginCountBean(){
          count = 1;
     public boolean checkSessieObject(){
          boolean retry = true;
          loginTries = (String) pageContext.findAttribute("logins");
          if(loginTries == null){
               count = 1;
               logins = new Integer(count);
               setSessieObject(logins);
          } else{
               count = Integer.parseInt((String) pageContext.findAttribute("logins"));
               if(count >= 3){
                    retry = false;
               } else{
                    count++;
                    logins = new Integer(count);
                    pageContext.setAttribute("logins", logins, PageContext.SESSION_SCOPE);
          return retry;
     public void setSessieObject(Integer logins){
          request.getSession();
          pageContext.setAttribute("logins", logins, PageContext.SESSION_SCOPE);
}

How does the bean get the request and pageContext objects?

Message Retry Count Zero error

Hi,
I am sending a Message from one Trading partner to another over ebMS protocol .
The trading partners are using Weblogic JMS queues as the internal delivery channels.
when one trading partner is sending message to another, the mesage comes to the receving trading partner with error as "Max retry count for Message is zero".
I have reffered to one of the thread (Re: FTP retry issue) which says "Can you please update the Retry count and time to acknowledge in the<br />Delivery channel page and update the polling interval in the transport<br />server page as empty? I think the Polling interval value overrides the<br />retry count."
I have followed this and I am getting a Transport Error.
Please Help!
With Thanks & Regards,
Suhas.

Hi,
This is the idc log:
2008.11.04 at 10:14:52:614: B2BStarter thread: (DEBUG) TransportProperties.TransportProperties():transport_callout_waittime=30;http.receiver.registry_port=5110;port=60700;smtp.receiver.protocol=imap;PROTOCOL_ENDPOINT=null;http.receiver.instance_name=IP;
2008.11.04 at 10:14:52:615: B2BStarter thread: (DEBUG) initialize TransportReceiver: [BTGS_ebMS_Transport_Server < http > < BTGS >]
2008.11.04 at 10:14:52:617: B2BStarter thread: (STATUS) [IPT_HttpRecRegisterBegin] HTTPReceiver.init(): Registering HTTP Receiver ...
2008.11.04 at 10:14:52:618: B2BStarter thread: (STATUS) RMIResponsePort = null
2008.11.04 at 10:14:53:020: B2BStarter thread: (STATUS) low port = 5110
2008.11.04 at 10:14:53:022: B2BStarter thread: (STATUS) high port = 5110
2008.11.04 at 10:14:53:023: B2BStarter thread: (STATUS) [IPT_HttpRecRegisterCompleted] HTTPReceiver.init(): Completed registering HTTP Receiver.
2008.11.04 at 10:14:55:987: RMI TCP Connection(13)-147.149.200.108: (STATUS) [IPT_HttpRecSendMessageViaCallback] A request is routed by HTTP Receiver to registered listener.
2008.11.04 at 10:14:58:018: Thread-14: (DEBUG) TransportProperties.TransportProperties():ACTION_NAME=ACTION:rqRequestTroubleReportAmendment;FROMROLE:Consumer;TOROLE:Provider;SERVICE:bcRequestTroubleReportConsumerAmendment_BT_V1;SERVICETYPE:string;;jms.sender.jndi_destination_provider_properties=java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://147.149.200.111:53482,147.149.200.111:53484;MSG_TYPE=1;MSG_ID=9395C86B11D66FF77B500000E555D000-1;TO_PARTY_IDENTIFIER=urn:oasis:names:tc:ebXML-cppa:partyid-type:duns#123456789;FROM_PARTY_IDENTIFIER=urn:oasis:names:tc:ebXML-cppa:partyid-type:duns#987654321;jms.sender.jndi_connection_factory_location=weblogic.jws.jms.QueueConnectionFactory;jms.sender.destination_password=******;jms.sender.factory_provider_properties=java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://147.149.200.111:53482,147.149.200.111:53484;jms.sender.jndi_destination_location=btgsb2b.distjms.WLI_to_CI_BPS_Cluster_1;jms.sender.is_topic=false;jms.sender.type=bytes;DOCTYPE_NAME=rqRequestTroubleReportAmendment_DocType;FROM_PARTY=BTW;DOCTYPE_REVISION=1.0;TO_PARTY=BTGS;jms.sender.destination_username=weblogic;
2008.11.04 at 10:14:58:020: Thread-14: (DEBUG) Establishing JMS Connection.
2008.11.04 at 10:14:58:431: Thread-14: (DEBUG) TransportProperties.TransportProperties():
2008.11.04 at 10:14:58:433: Thread-14: (DEBUG) TransportProperties.TransportProperties():http.sender.port=80;http.sender.proto=http;http.sender.host=punin1879164268.sid.bt.com;http.sender.path=/b2b/transportServlet;
2008.11.04 at 10:14:58:434: Thread-14: (DEBUG) Discard Existing Cookies for CurrentThreadContext = Thread[Thread-14,5,main]
2008.11.04 at 10:14:58:435: Thread-14: (DEBUG) Timeout = 60000
2008.11.04 at 10:14:58:436: Thread-14: (DEBUG) Basic authentication is not used due to one of security parameters not set. Make sure username, password, and realm are set in delivery channel.
2008.11.04 at 10:14:58:437: Thread-14: (DEBUG) http.sync = null
2008.11.04 at 10:14:58:438: Thread-14: (DEBUG) Number of headers to be added is 7
2008.11.04 at 10:14:58:932: Thread-14: (DEBUG) [IPT_HttpSendResponseStatusCode] HTTP Response status code: 204
2008.11.04 at 10:14:58:934: Thread-14: (DEBUG) [IPT_HttpSendResponseMessage] HTTP Response message: .
Regards,
Suhas.

Spin Retry count again (plz help)

Hi,
My 11 month old macbook pro (2011) was recently sent under warrenty for Harddisk SPIN RETRY COUNT value increase. They changed the harddisk and installed new Toshiba harddisk. Which ran 100% S.M.A.R.T health for two weeks and now it is showing same Spin retry count problem. I am thinking its not the harddisk but something else is causing the problem( may be power supply problem). I am from nepal so it takes a lot of effort to send it in for repair. Any help on this topic will really appreciated plz. Scaned it with disk radar and Techtool.

AFAIK, this SMART parameter indicates a mechanical problem. Which would mean that you've experienced two different hard disks with mechanical failure in a row in the same machine. While not impossible, I should expect this to be rather improbable.
A power supply issue may be the cause, but then I'd expect other symptoms as well. Here's what I'm thinking:
(1) SATA cable. Problems with SATA cables are common in laptops.
(2) Alternatively, a long shot: ambient air pressure. You mentioned Nepal. If you're in the Kathmandu Valley, it's not an issue; but if you take your MBP above, say, roughly 3200m, it may become a problem for the hard disk.

Sharing PIN try counter -CVM retry counter- EMV GP contactless payment card

I am trying to find out information regarding Pin try counter (referred to as the CVM retry counter in the the Global Platform 2.1.1 specs). We require a multi application card - one Mchip application and one proprietary application - The GP spec states that the PIN is shared accross applications (global PIN) however I am trying to find out the status of PIN try counter -can it be shared accross applications or is this not feasible? Also same question regarding the application transaction counter (ATC).
GP spec is not clear on this - but it seems that counter sharing is not a requirement. Even if not a requirement, is it possible? Thanks
GP spec states:
The CVM state may be used by an Application to assist in managing PIN related functions. The non-atomic states
of the CVM may be seen within a Card Session. The CVM state, the Retry Limit, and the Retry Counter are
closely related. All CVM state transitions are immediately visible to the Application that caused the transition as
well as to any Applications that may be selected on other logical channels.

Thanks for your reply. Pin try counter (PTC) sharing is very common in contact EMV cards, we have been led to believe that there is an architecture issue in the contactless cards that makes PTC sharing more difficult (no problem with our Mchip contact cards with same applictions resident). From what I understand, in the contactless environment, firewalls exist around each "application" that prevent the sharing of most data other that the global PIN.
We require the PTC to be shard for the use case in which the PTC is blown and a PTC reset script must be sent to the card. The scripts generally only update data in the active appliction and not the other apps residing on the card, therefore if you have multiple PTCs, the correct one might not be updated by the script. This is very problematic for us.

My Satellite notebook shows "Spin retry count" warning

Hi first time user hope I get this write, I am using system mechanic pro latest version and on the hard drive monitor status it is showing a warning for the spin retry count.
My laptop is only 2 months old should I be worried? and have it looked at. Thanks in advance. Operating system is win8.1

In my opinion there is no reason for panic. You are using third part software and they have own rule for reporting S.M.R.T values.
If there is no other problem I think everything is OK.
Open preinstalled PC health monitor and check HDD Status. What is reported there?
I hope Good.

Instead of Retry Count is to 0,file is coming twise in OSB.

In my OSB project ,the xml file is polling from a folder ,after that it is transformed through Xquery,then it goes to a DB. I have added a route level error handeller ,if any error occurs a file will be generated with this payload and stored in a folder. Everything is working fine.but if any error occurs then all time 2 file is generated.though retry.count=0 in adapter and business service also,where did i make mistake,please advise..

Please provide some valuable answer. I am not able to understand why this is happening????
Thanks!!

Fault policy and jca.retry.count in 11g

I have a composite which has the architecture as follows :
Adapter (File) -- Mediator -- Adapter (FTP)
The mediator follows sequential routing pattern
I have configured jta.retry.count = 3 for the FTP adapter.
Also the composite refers to the fault policy file from the MDS
In the fault policy file the ora retry action is defined as follows :
< Action id="ora-retry">
<retry>
<retryCount>1</retryCount>
<retryInterval>5</retryInterval>
<retryFailureAction ref="ora-rethrow-fault"/>
</retry>
</Action>
We have configured the following rejection handler for the file adapter :
<faultName xmlns:rjm="http://schemas.oracle.com/sca/rejectedmessages"
name="rjm:FILE_RD_B2BOutFolder_Files">
<condition>
<action ref="ora-ws"/>
</condition>
</faultName>
We get the following message as part of rejection message email notification :
The adapter has exceeded maximum configured retries. The adapter has exceeded maximum configured retries. The adapter was unable to process "{0}" after having retried for {1} times, now the adapter will reject the message. This exception usually comes due to errors in downstream systems. Please increase the value for "jca.retry.maxRetries" in composite.xml for the inbound service and redeploy.
I have the following doubts:
1. When the FTP adapter fails because of a remote fault, which retry will be executed fault policy or jta.retry.count ?
2. If the jta.retry.count is executed then can I see 3 instances on the EM console or any other entry in the Log file.
3. where can i configure jca.retry.maxretries property. this property is not available on emconsole.

Hi,
Section 12.4.4 and 12.4.5 should answer your questions.
http://docs.oracle.com/cd/E12839_01/integration.1111/e10224/bp_faults.htm#BABICJAD
Regards,
Neeraj Sehgal

Retry count & interval problem

Similar Messages

Maybe you are looking for