Trying to get cert-manager setup with AKS and getting the following back in logs:
I1121 14:33:59.875981 1 pod.go:59] cert-manager/challenges/http01/selfCheck/http01/ensurePod "msg"="found one existing HTTP01 solver pod" "dnsName"="workspace.uat.api.t4s.tofu.solutions" "related_resource_kind"="Pod" "related_resource_name"="cm-acme-http-solver-zc2hg" "related_resource_namespace"="default" "related_resource_version"="v1" "resource_kind"="Challenge" "resource_name"="t4s-workspace-tls-secret-7bwmr-1917165212-3959223356" "resource_namespace"="default" "resource_version"="v1" "type"="HTTP-01" I1121 14:33:59.876058 1 service.go:43] cert-manager/challenges/http01/selfCheck/http01/ensureService "msg"="found one existing HTTP01 solver Service for challenge resource" "dnsName"="workspace.uat.api.t4s.tofu.solutions" "related_resource_kind"="Service" "related_resource_name"="cm-acme-http-solver-2xgd6" "related_resource_namespace"="default" "related_resource_version"="v1" "resource_kind"="Challenge" "resource_name"="t4s-workspace-tls-secret-7bwmr-1917165212-3959223356" "resource_namespace"="default" "resource_version"="v1" "type"="HTTP-01" I1121 14:33:59.876110 1 ingress.go:99] cert-manager/challenges/http01/selfCheck/http01/ensureIngress "msg"="found one existing HTTP01 solver ingress" "dnsName"="workspace.uat.api.t4s.tofu.solutions" "related_resource_kind"="Ingress" "related_resource_name"="cm-acme-http-solver-9k7hl" "related_resource_namespace"="default" "related_resource_version"="v1" "resource_kind"="Challenge" "resource_name"="t4s-workspace-tls-secret-7bwmr-1917165212-3959223356" "resource_namespace"="default" "resource_version"="v1" "type"="HTTP-01" E1121 14:33:59.885334 1 sync.go:190] cert-manager/challenges "msg"="propagation check failed" "error"="wrong status code '470', expected '200'" "dnsName"="workspace.uat.api.t4s.tofu.solutions" "resource_kind"="Challenge" "resource_name"="t4s-workspace-tls-secret-7bwmr-1917165212-3959223356" "resource_namespace"="default" "resource_version"="v1" "type"="HTTP-01"
It may be something with our firewall settings but I want to find out what endpoint do we need to free up to complete the HTTP-01 chanllenge?
Thanks a lot for any help available in advance!
Expecting the HTTP-01 challenge should work but getting HTTP 470 as a response code.
Related
I am trying to test 270 Eligibility Request for BCBS Texas through Availity but it always returns AAA*N79*C~** error after NM*PR line. I am really new to this and have no idea what could be wrong with the 270 request. I tried to search AAA error and it seems that PayerID in NM1 line is not identified by Availity and maybe incorrect but I tried different insurance companies(Aetna FL and United Healthcare Oxford Navigate) and they are also returned with same error at exact same line(they have different PayerID in their 270 file).
Any help would be appreciated on this issue, I know I am messing up something in 270 request for sure but don't know exactly what is messed up.
270 Request:
ISA*00* *00* *ZZ*AV09311993 *01*123456789 *200110*0818*^*00501*000000193*1*P*:~
GS*HS*AV01101957*123456789*20200110*0818*000000193*X*005010X279A1~
ST*270*0001*005010X279A1~
BHT*0022*13*244579*20200110*0818~
HL*1**20*1~
NM1*PR*2*BCBSTX*****PI*84980~
HL*2*1*21*1~
NM1*1P*2*Provider Name*****SV*1234567890~
NM1*40*2*AVAIL*****46*030240928~
HL*3*2*22*0~
TRN*1*00012*1234567890~
NM1*IL*1******MI*ABC1234567~
DTP*291*RD8*20100101-20200110~
EQ*30~
SE*13*0001~
GE*1*000000193~
IEA*1*000000193~
271 Response:
ISA*00* *00* *01*123456789 *ZZ*AV09311993 *200112*0816*^*00501*220190332*0*P*:~
GS*HB*123456789*AV01101957*20200112*0816*123456789*X*005010X279A1~
ST*271*1001*005010X279A1~
BHT*0022*11*244579*20200110*0818~
HL*1**20*1~
NM1*PR*2*BCBSTX*****PI*84980~
AAA*N**79*C~
HL*2*1*21*1~
NM1*1P*2*Provider Name*****SV*1234567890~
HL*3*2*22*0~
TRN*2*00012*1234567890~
NM1*IL*1******MI*ABC1234567~
DTP*291*RD8*20100101-20200110~
EB*V~
SE*13*1001~
GE*1*123456789~
IEA*1*220190332~
79 Invalid Participant Identification
Description: Use this code to indicate that the value in either GS02 or GS03 is invalid.
I am assuming you are using an incorrect payer ID. Try using the following:
some other team is calling our FileNet custom app for searching documents. I believe some of the users are facing intermittent failure because we are getting tickets(although none of the user has reported this issue) for the error below and I tried validating our service with different scenarios and they all worked but I don't know what's causing this error. any suggestions/help would be greatly appreciated.
<stackTrace>
at com.filenet.apiimpl.transport.ejb.EJBSession.throwException(EJBSession.java:1122)
at com.filenet.apiimpl.transport.ejb.EJBSession.throwException(EJBSession.java:1045)
at com.filenet.apiimpl.transport.ejb.EJBSession$EJBImpl._getObjects(EJBSession.java:650)
at com.filenet.apiimpl.transport.ejb.EJBSession$EJBImpl.getObjects(EJBSession.java:575)
at com.filenet.apiimpl.transport.ejb.EJBSession.getObjects(EJBSession.java:471)
at com.filenet.apiimpl.util.SessionHandle.getObjects(SessionHandle.java:346)
at com.filenet.apiimpl.core.Session.callGetObjects(Session.java:132)
at com.filenet.apiimpl.core.Session.executeGetObject(Session.java:340)
at com.filenet.apiimpl.core.Session.getObject(Session.java:354)
at com.filenet.apiimpl.core.DispatchEntries.FetchObject_28(DispatchEntries.java:907)
at com.filenet.apiimpl.core.ObjectStoreImpl.fetchObject(ObjectStoreImpl.java:1643)
at com.filenet.api.core.Factory$ClassDescription.fetchInstance(Factory.java:21761)
at ecm.service.p8ceservices.implementation.integration.SearchP8ObjectAdapter.retrievePropertyDefinitions(SearchP8ObjectAdapter.java:352)
at ecm.service.p8ceservices.implementation.integration.SearchP8ObjectAdapter.integrate(SearchP8ObjectAdapter.java:158)
at ecm.service.p8ceservices.implementation.integration.ContentEngineAdapter.execute(ContentEngineAdapter.java:37)
</stackTrace>
</exception><exception name="java.lang.IndexOutOfBoundsException" message="Data to be copied (length 2124) exceeds space available (480)" sequence="0" guid="sfr2mx3l:jewe2wkf:00000000:00000121"><source class="com.ibm.rmi.util.buffer.SimpleByteBuffer" archive="" vendor="" version="" /><stackTrace>
at com.ibm.rmi.util.buffer.SimpleByteBuffer.write(SimpleByteBuffer.java:166) at com.ibm.rmi.iiop.ClientRequestImpl.reInvoke(ClientRequestImpl.java:489)
at com.ibm.rmi.corba.ClientDelegate.invoke(ClientDelegate.java:637) at com.ibm.CORBA.iiop.ClientDelegate.invoke(ClientDelegate.java:1377)
at com.ibm.rmi.corba.ClientDelegate.invoke(ClientDelegate.java:695) at com.ibm.CORBA.iiop.ClientDelegate.invoke(ClientDelegate.java:1407)
at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:484) at com.filenet.apiimpl.transport.ejbstubs._Engine_Stub.getObjects(Unknown Source)
at com.filenet.apiimpl.transport.ejb.EJBSession$EJBImpl._getObjects(EJBSession.java:638)</stackTrace>
It could be the following issue:
ClientRequestImpl.reInvoke retry requests which failed due to errors.
The retry itself fails with IndexOutOfBoundsException because ORB is using fixed length SimpleByteBuffer.
See also this IBM Fix
I've recorded a workflow using proxy recorder for a mobile application which is using API calls in VUGEN(loadrunner 12.55). I am getting internal server error 500 during update (POST) function. Following is the code snippet of script generated by Loadrunner
web_submit_data("signin",
"Action=http://beautymarksapp.com/api/user/signin",
"Method=POST",
"RecContentType=application/json",
"Referer=",
"Snapshot=t1.inf",
"Mode=HTML",
"EncodeAtSign=YES",
ITEMDATA,
"Name=email", "Value=user#domain.com", ENDITEM,
"Name=password", "Value=BMARKS", ENDITEM,
"Name=timezone", "Value=18000", ENDITEM,
LAST);
web_custom_request("update",
"URL=http://beautymarksapp.com/api/user/update",
"Method=PUT",
"Resource=0",
"RecContentType=application/json",
"Referer=",
"Snapshot=t2.inf",
"Mode=HTML",
"Body=device_token=c7ff93995d1dea60fea773819b582235b6367c0c7275238a65c2035c2d96fde6&device_type=ios",
LAST);
Any help in this regard will be highly appreciated.
The most common answer for 500 are:
Unhandled Dynamic Item
No checking for expected results
No exception handling/branching when unexpected results appear
I recently set up a new app server (Ruby 1.8.7 REE, Rails 2.3.8, Passenger 3.0.9, Nginx 1.0.6) behind a proxy and am encountering some strange behavior. When posting to /login on this app server alone, I get a 502 Bad Gateway error. This does not happen on the other app server, and both are set up identically. I've narrowed the problem down to a specific line of code - the saving of an Authlogic session. When I comment out these lines (specifically the save call):
#user_session = UserSession.new(params[:user_session])
if #user_session.save
...
the 502 error no longer occurs. Likewise, when I test these commands in the console, I get an Illegal Instruction response and the console crashes:
>> Authlogic::Session::Base.controller = Authlogic::ControllerAdapters::RailsAdapter.new(self)
>> #user_session = UserSession.new({"password"=>"password", "remember_me"=>"0", "login"=>"myuser"})
>> #user_session.save
Illegal instruction
Testing this on the other app server works just fine (console does not crash with Illegal Instruction result).
Any idea where to begin troubleshooting this? I see nothing of value in either the Rails logs or the Nginx logs.
Thanks.
Edit
The Illegal Instruction is occurring during a system call to digest.rb. The same thing happens whether I use the Ubuntu Ruby Enterprise Edition package or whether I compile it myself:
stat("/opt/ruby-enterprise-1.8.7-2011.12/lib/ruby/1.8/digest.rb", {st_mode=S_IFREG|0644, st_size=1145, ...}) = 0
open("/opt/ruby-enterprise-1.8.7-2011.12/lib/ruby/1.8/digest.rb", O_RDONLY) = 15
fstat(15, {st_mode=S_IFREG|0644, st_size=1145, ...}) = 0
close(15) = 0
--- SIGILL (Illegal instruction) # 0 (0) ---
This sounds like it's related to Ruby 1.9 Ramaze App Failing with “Illegal instruction”.
Jörg W Mittag said:
"Illegal instruction" is usually an error message from the CPU meaning some piece of binary code you tried to run contained an instruction that is not implemented on that particular CPU.
This can have multiple reasons:
The binary was compiled with optimization settings for the wrong CPU. The CPU vendors add new instructions all the time, if the compiler optimizes for a CPU that is newer than the one you have, it might have emitted an instruction that your CPU doesn't understand.
The compiler is broken.
The binary is corrupted.
The code you are compiling contains assembly code or intrinsics containing instructions that your CPU doesn't have.
The original question submitter Phil Kulak replied that he had found a stack overflow causing the error.
We are using distributed JMS on weblogic and some times ResourceAccessException occurs. We tried deleting filestores, restarting servers and changing JTA timeout to 300 seconds. (default is 30 seconds).
But we are getting the same error. What could be the reason?
Thanks
Caused by: javax.transaction.SystemException: start() failed on resource 'WLStore_COLUMBUS-ADA-PROD-DMN_ColumbusADAFileStore': XAER_RMERR : A resource manager error has occured in the transaction branch
weblogic.transaction.internal.ResourceAccessException: Transaction has timed out when making request to XAResource 'WLStore_COLUMBUS-ADA-PROD-DMN_ColumbusADAFileStore'.
at weblogic.transaction.internal.XAResourceDescriptor.startResourceUse(XAResourceDescriptor.java:670)
at weblogic.transaction.internal.XAServerResourceInfo.start(XAServerResourceInfo.java:1230)
at weblogic.transaction.internal.XAServerResourceInfo.xaStart(XAServerResourceInfo.java:1164)
at weblogic.transaction.internal.XAServerResourceInfo.enlist(XAServerResourceInfo.java:296)
at weblogic.transaction.internal.ServerTransactionImpl.enlistResource(ServerTransactionImpl.java:522)
at weblogic.transaction.internal.ServerTransactionImpl.enlistResource(ServerTransactionImpl.java:449)
at weblogic.store.gxa.internal.GXAResourceImpl.enlist(GXAResourceImpl.java:442)
at weblogic.messaging.kernel.internal.KernelImpl.getGXATransaction(KernelImpl.java:570)
at weblogic.messaging.kernel.internal.QueueImpl.send(QueueImpl.java:329)
at weblogic.jms.backend.BEDestinationImpl.sendIssueMessage(BEDestinationImpl.java:1873)
at weblogic.jms.backend.BEDestinationImpl.send(BEDestinationImpl.java:2108)
at weblogic.jms.backend.BEDestinationImpl.wrappedSend(BEDestinationImpl.java:2051)
at weblogic.jms.backend.BEDestinationImpl.invoke(BEDestinationImpl.java:1539)
at weblogic.messaging.dispatcher.Request.wrappedFiniteStateMachine(Request.java:961)
at weblogic.messaging.dispatcher.DispatcherImpl.dispatchAsyncInternal(DispatcherImpl.java:139)
at weblogic.messaging.dispatcher.DispatcherImpl.dispatchAsync(DispatcherImpl.java:115)
at weblogic.messaging.dispatcher.Request.dispatchAsync(Request.java:1303)
at weblogic.jms.dispatcher.Request.dispatchAsync(Request.java:96)
at weblogic.jms.frontend.FEProducer.doDispatch(FEProducer.java:888)
at weblogic.jms.frontend.FEProducer.sendRetryDestination(FEProducer.java:1021)
at weblogic.jms.frontend.FEProducer.send(FEProducer.java:1405)
at weblogic.jms.frontend.FEProducer.invoke(FEProducer.java:1466)
at weblogic.messaging.dispatcher.Request.wrappedFiniteStateMachine(Request.java:961)
at weblogic.messaging.dispatcher.DispatcherImpl.syncRequest(DispatcherImpl.java:184)
at weblogic.messaging.dispatcher.DispatcherImpl.dispatchSyncNoTran(DispatcherImpl.java:287)
at weblogic.jms.dispatcher.DispatcherAdapter.dispatchSyncNoTran(DispatcherAdapter.java:59)
at weblogic.jms.client.JMSProducer.toFEProducer(JMSProducer.java:1293)
at weblogic.jms.client.JMSProducer.deliveryInternal(JMSProducer.java:796)
at weblogic.jms.client.JMSProducer.sendInternal(JMSProducer.java:541)
at weblogic.jms.client.JMSProducer.sendWithListener(JMSProducer.java:394)
at weblogic.jms.client.JMSProducer.send(JMSProducer.java:384)
at weblogic.jms.client.WLProducerImpl.send(WLProducerImpl.java:970)
at org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:592)
at org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:569)
at org.springframework.jms.core.JmsTemplate$4.doInJms(JmsTemplate.java:546)
at org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:466)
at org.springframework.jms.core.JmsTemplate.send(JmsTemplate.java:543)
at com.turkcellteknoloji.calypso.jms.SendToJms.insertJms(SendToJms.java:35)
at com.turkcellteknoloji.calypso.action.impl.SentTransactionToJms.execute(SentTransactionToJms.java:15)
at com.turkcellteknoloji.calypso.service.impl.Service.execute(Service.java:36)
at com.turkcellteknoloji.calypso.service.impl.JmsService.onMessage(JmsService.java:21)
at com.turkcellteknoloji.calypso.service.impl.JmsService.onMessage(JmsService.java:12)
at org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:534)
at org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:495)
at org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:467)
at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:323)
at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:261)
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:977)
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:969)
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:871)
at java.lang.Thread.run(Thread.java:619)
Caused by: weblogic.transaction.internal.TimedOutException: Transaction has timed out when making request to XAResource 'WLStore_COLUMBUS-ADA-PROD-DMN_ColumbusADAFileStore'.
at weblogic.transaction.internal.XAResourceDescriptor.startResourceUse(XAResourceDescriptor.java:673)
... 50 more
at weblogic.transaction.internal.XAServerResourceInfo.xaStart(XAServerResourceInfo.java:1188)
at weblogic.transaction.internal.XAServerResourceInfo.enlist(XAServerResourceInfo.java:296)
at weblogic.transaction.internal.ServerTransactionImpl.enlistResource(ServerTransactionImpl.java:522)
at weblogic.transaction.internal.ServerTransactionImpl.enlistResource(ServerTransactionImpl.java:449)
at weblogic.store.gxa.internal.GXAResourceImpl.enlist(GXAResourceImpl.java:442)
... 44 more
Have you tried to change the"Synchronous Write Policy"? It affects the JMS file store's performance, scalability, and reliability.
Adding similar issue found with Weblogic hosted application kept failing with little or no reason with stack trace:
Caused by: weblogic.jms.common.JMSException: weblogic.messaging.kernel.KernelException: Error enlisting GXA transaction
at weblogic.jms.dispatcher.DispatcherAdapter.convertToJMSExceptionAndThrow(DispatcherAdapter.java:110)
at weblogic.jms.dispatcher.DispatcherAdapter.dispatchSyncTran(DispatcherAdapter.java:53)
at weblogic.jms.client.JMSProducer.toFEProducer(JMSProducer.java:1300)
at weblogic.jms.client.JMSProducer.deliveryInternal(JMSProducer.java:807)
at weblogic.jms.client.JMSProducer.sendInternal(JMSProducer.java:543)
at weblogic.jms.client.JMSProducer.sendWithListener(JMSProducer.java:394)
at weblogic.jms.client.JMSProducer.send(JMSProducer.java:384)
at weblogic.jms.client.WLProducerImpl.send(WLProducerImpl.java:970)
at weblogic.deployment.jms.WrappedMessageProducer.send(WrappedMessageProducer.java:188)
at org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:626)
at org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:597)
at org.springframework.jms.core.JmsTemplate$3.doInJms(JmsTemplate.java:562)
at org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:484)
With little information available, followed some other suggestions to re-create the JMS data store which could have been corrupted.
In our case located here:
..fmw_home/user_projects/domains/ipp_domain/servers/myapplicationName/data/store/default - filename WLS******.DAT
A graceful shutdown to allow as many as possible messages to be resolved is suggested, then shut down application and Weblogic Server before removing the file (would suggest a backup).
After a restart, these issues disappeared, and no more errors were logged, but I'm not sure what the cause was. You would probably have to accept that any transactional data in the JMS queue will be lost.