Exception when triggering Manual Invoice Match process

[Rowan]

Hi there,

I am getting a java.rmi exception -Unable to reach host when triggering the manual match invoice process on the match errors screen for an invoice that has match errors. I have turned on the logs and am unable to figure out from the stuff that has been logged.

Thanks,
Rohan

[Rowan]

Re: Exception when triggering Manual Invoice Match process

I receive the following exception:

Generic Remote Exception

java.rmi.ConnectException: Unable to reach host
From the Stack Trace:

At2008-02-06 22:53:27.454Generic_Remote_Exception
java.rmi.ConnectException: Unable to reach host

java.rmi.ConnectException: Unable to reach host
at weblogic.rmi.internal.BasicRemoteRef.getOutboundRe quest(BasicRemoteRef.java:86)
at weblogic.rmi.internal.BasicRemoteRef.invoke(BasicR emoteRef.java:126)
at glog.ejb.invoice.ejb_Invoice_tnpbf2_HomeImpl_814_W LStub.findByPrimaryKey(Unknown Source)
at glog.webserver.uic.GetShipmentNote.getDocument(Get ShipmentNote.java:51)
at glog.webserver.util.QueryResponseServlet.getDocume nt(QueryResponseServlet.java:167)
at glog.webserver.util.AbstractServletProducer.proces s(AbstractServletProducer.java:80)
at glog.webserver.util.BaseServlet.service(BaseServle t.java:591)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:802)
at org.apache.catalina.core.ApplicationFilterChain.in ternalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.do Filter(ApplicationFilterChain.java:173)
at glog.webserver.screenlayout.ClientSessionTracker.d oFilter(ClientSessionTracker.java:54)
at org.apache.catalina.core.ApplicationFilterChain.in ternalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.do Filter(ApplicationFilterChain.java:173)
at glog.webserver.util.SetCharacterEncodingFilter.doF ilter(SetCharacterEncodingFilter.java:44)
at org.apache.catalina.core.ApplicationFilterChain.in ternalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.do Filter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invo ke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invo ke(StandardContextValve.java:17
at org.apache.catalina.core.StandardHostValve.invoke( StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invok e(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.servic e(CoyoteAdapter.java:14
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyo teHandler.java:307)
at org.apache.jk.common.HandlerRequest.invoke(Handler Request.java:385)
at org.apache.jk.common.ChannelSocket.invoke(ChannelS ocket.java:74
at org.apache.jk.common.ChannelSocket.processConnecti on(ChannelSocket.java:67
at org.apache.jk.common.SocketConnection.runIt(Channe lSocket.java:871)
at org.apache.tomcat.util.threads.ThreadPool$ControlR unnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:534)

This error seems like, it is masking something else (i.e. some other error message)

When searching through oracle support I found the following:
57322.5.0 ISS00020134 Cannot use the action 'approve invoice' : Generic_Remote_Exception java.rmi.ConnectException: Unable to reach host The manual invoice action Approve Invoice currently checks the invoice status to determine if it should follow an approval or adjustment process flow. Fixed an error where this status check sometimes caused a "Generic_Remote_Exception,
Unable to reach host" error.[FONT=tahoma,verdana,geneva,lucida,'lucida grande',arial,helvetica,sans-serif]I am not too sure why this exception is happening for all the invoices. It could be data issue or something else.
I have checked the sql logged in the logs.

Rohan
[/FONT]

[chrisplough]

Re: Exception when triggering Manual Invoice Match process

Rohan,

This message shows that the RMI call is unable to connect to https://mts.toll.com.au. Knowing a little bit about your architecture, this may be due to a couple of things:

1) Since reverse-proxies are in place ahead of the OTM application, they may not be handling the redirects correctly -- for instance the link https://mts.toll.com.au/images/spacer.gif should have an associated URL prefix that allows the reverse-proxy to identify the correct back-end system.

2) There may be a bug in the OTM software, that is causing it not to correctly "reverse-proxy enable" this action.

3) It may be that https is not enabled internally and that http needs to be used. For instance, I know that you use https coming into the reverse-proxy, but use http for everything behind that. As a result, I'm not sure if your basic OTM instance is https enabled.

Thanks,
Chris