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.
Related
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 am getting below error in logs while fetching Jira issues on particular JQL. I have set a schedular to run that JQL every 30 mins to sync the retrieved issues to another tool.
java.util.concurrent.ExecutionException: java.lang.RuntimeException: java.util.concurrent.TimeoutException
at com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:294)
at com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:267)
at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:96)
at com.google.common.util.concurrent.ForwardingFuture.get(ForwardingFuture.java:69)
at com.asurion.Autopilot.main(Autopilot.java:104)
Caused by: java.lang.RuntimeException: java.util.concurrent.TimeoutException
at com.google.common.base.Throwables.propagate(Throwables.java:160)
at com.atlassian.httpclient.apache.httpcomponents.DefaultHttpClient$3.apply(DefaultHttpClient.java:256)
at com.atlassian.httpclient.apache.httpcomponents.DefaultHttpClient$3.apply(DefaultHttpClient.java:249)
at com.atlassian.util.concurrent.Promises$Of$2.apply(Promises.java:276)
at com.atlassian.util.concurrent.Promises$Of$2.apply(Promises.java:272)
at com.atlassian.util.concurrent.Promises$2.onFailure(Promises.java:167)
at com.google.common.util.concurrent.Futures$6.run(Futures.java:801)
at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:262)
at com.google.common.util.concurrent.ExecutionList$RunnableExecutorPair.execute(ExecutionList.java:149)
at com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:134)
at com.google.common.util.concurrent.AbstractFuture.setException(AbstractFuture.java:193)
at com.google.common.util.concurrent.SettableFuture.setException(SettableFuture.java:68)
at com.atlassian.httpclient.apache.httpcomponents.SettableFuturePromiseHttpPromiseAsyncClient$1$3.run(SettableFuturePromiseHttpPromiseAsyncClient.java:73)
at com.atlassian.httpclient.apache.httpcomponents.SettableFuturePromiseHttpPromiseAsyncClient$ThreadLocalDelegateRunnable$1.run(SettableFuturePromiseHttpPromiseAsyncClient.java:197)
at com.atlassian.httpclient.apache.httpcomponents.SettableFuturePromiseHttpPromiseAsyncClient.runInContext(SettableFuturePromiseHttpPromiseAsyncClient.java:90)
at com.atlassian.httpclient.apache.httpcomponents.SettableFuturePromiseHttpPromiseAsyncClient$ThreadLocalDelegateRunnable.run(SettableFuturePromiseHttpPromiseAsyncClient.java:192)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.util.concurrent.TimeoutException
at com.atlassian.httpclient.apache.httpcomponents.SettableFuturePromiseHttpPromiseAsyncClient$1.doCancelled(SettableFuturePromiseHttpPromiseAsyncClient.java:67)
at com.atlassian.httpclient.apache.httpcomponents.SettableFuturePromiseHttpPromiseAsyncClient$ThreadLocalContextAwareFutureCallback$3.run(SettableFuturePromiseHttpPromiseAsyncClient.java:152)
at com.atlassian.httpclient.apache.httpcomponents.SettableFuturePromiseHttpPromiseAsyncClient.runInContext(SettableFuturePromiseHttpPromiseAsyncClient.java:90)
at com.atlassian.httpclient.apache.httpcomponents.SettableFuturePromiseHttpPromiseAsyncClient$ThreadLocalContextAwareFutureCallback.cancelled(SettableFuturePromiseHttpPromiseAsyncClient.java:147)
at org.apache.http.impl.client.cache.CachingHttpAsyncClient$2.cancelled(CachingHttpAsyncClient.java:636)
at org.apache.http.concurrent.BasicFuture.cancel(BasicFuture.java:150)
at org.apache.http.impl.nio.client.DefaultResultCallback.cancelled(DefaultResultCallback.java:57)
at org.apache.http.impl.nio.client.DefaultAsyncRequestDirector.cancel(DefaultAsyncRequestDirector.java:533)
at org.apache.http.impl.nio.client.DefaultAsyncRequestDirector$1.abortConnection(DefaultAsyncRequestDirector.java:222)
at org.apache.http.client.methods.HttpRequestBase.cleanup(HttpRequestBase.java:137)
at org.apache.http.client.methods.HttpRequestBase.abort(HttpRequestBase.java:151)
at com.atlassian.httpclient.base.RequestKiller$RequestEntry.abort(RequestKiller.java:98)
at com.atlassian.httpclient.base.RequestKiller.run(RequestKiller.java:56)
... 1 more
This error is occurring frequently but not continuous. Sometime it works, many times it won't.
Jira Version: 7.1.4#71008
Jira REST Java Client Version: 2.0.0-m2
JIRA REST java-client-core Version: 2.0.0-m25
Please let me know if you need more details.
Thanks in advance.
Regards,
Tushar
Looks like a timeout on your request, which comes and goes depending on server load. Can you streamline or break up the query, set a longer timeout, or put other activity on the server on hold during the sync?
There was some issue with Jira server. We don't have access to it, but after few days the issue seems to be gone. Not sure what has happened at Jira side.
Users of an application that I work on are reporting this particular exception with neo4j 2.1.1. This appears to be sporadic and difficult to reproduce. Is this a known issue, or is it associated with any particular misuse or error? I would love to provide more information on how to reproduce this, but I cannot.
The code that creates this stacktrace is really dead simple:
Node n = null;
try (Transaction tx = db.beginTx()) {
n = db.createNode();
// Lots of extra code snipped here because it never makes it that far...
}
The exception seems to be thrown on the createNode() method:
SEVERE: Servlet.service() for servlet [Jersey REST Service] in context with path [/plus] threw exception
org.neo4j.kernel.impl.persistence.ResourceAcquisitionFailedException: TM encountered an unexpected error condition.
at org.neo4j.kernel.impl.persistence.PersistenceManager$ResourceHolder.enlist(PersistenceManager.java:412)
at org.neo4j.kernel.impl.persistence.PersistenceManager$ResourceHolder.forWriting(PersistenceManager.java:394)
at org.neo4j.kernel.impl.api.KernelTransactionImplementation.ensureWriteTransaction(KernelTransactionImplementation.java:190)
at org.neo4j.kernel.impl.api.KernelTransactionImplementation.upgradeToDataTransaction(KernelTransactionImplementation.java:220)
at org.neo4j.kernel.impl.api.KernelStatement.dataWriteOperations(KernelStatement.java:83)
at org.neo4j.kernel.InternalAbstractGraphDatabase.createNode(InternalAbstractGraphDatabase.java:1107)
at org.mitre.provenance.db.neo4j.Neo4JStorage.store(Neo4JStorage.java:1101)
(big stack of servlet related exceptions snipped out here that)
At the bottom, there is this:
Caused by: javax.transaction.RollbackException: Tx status is: STATUS_MARKED_ROLLBACK
at org.neo4j.kernel.impl.transaction.TransactionImpl.enlistResource(TransactionImpl.java:191)
at org.neo4j.kernel.impl.persistence.PersistenceManager$ResourceHolder.enlist(PersistenceManager.java:405)
... 45 more
A lot of fixes have been applied since 2.1.1, so make sure to run on the latest stable version (2.1.4 as of today). If the problem persists on 2.1.4, consider filing a github issue at https://github.com/neo4j/neo4j/issues/new
Our Nightly TFS 2012 backup has just started to fail. It also fails when run directly through TFS Express Administration Console.
Which file is the following error actually referring to? If I can find it then I should be able to fix the "Root element is missing" error :)
[13/08/2014 23:00:00] [Info] Full database backup job
[13/08/2014 23:00:00] [Info] Getting backup lock
[13/08/2014 23:00:05] [Error]
Exception Message: There is an error in XML document (0, 0). (type InvalidOperationException)
Exception Stack Trace: at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events)
at Microsoft.TeamFoundation.Admin.BackupSets.Load(String folder)
at Microsoft.TeamFoundation.Admin.Jobs.FullDatabaseBackupJobExtension.Run(TeamFoundationRequestContext requestContext, TeamFoundationJobDefinition jobDefinition, DateTime jobQueueTime, String& resultMessage)
Inner Exception Details:
Exception Message: Root element is missing. (type XmlException)
Exception Stack Trace: at System.Xml.XmlTextReaderImpl.ThrowWithoutLineInfo(String res)
at System.Xml.XmlTextReaderImpl.ParseDocumentContent()
at System.Xml.XmlReader.MoveToContent()
at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderBackupSets.Read7_BackupSets()
[13/08/2014 23:00:05] [Info] Full Backups Failed
Thanks.
Dylan answered my original question as to where to find the unspecified xml file that was in error, but in case it helps anyone else...
The Backupsets.xml file was empty. Why this is I do not know...
Attempting to configure backups through TFS Express Administration Console also failed with the same error, so I
Deleted the Backupsets.xml file altogether
Reconfigured Backups using the wizard - Now that it didn't find the xml file at all it created a new one.
Ran a full backup - which was sucessful. Hopefully the scheduled backups will now also work from now on.
NB The newly created Backupsets.xml file (Before the first full backup) :
<?xml version="1.0"?>
<BackupSets xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Version>1</Version>
<BackupSets />
</BackupSets>
Look in the folder where your backups are configured to be placed. there will be an XML file there, can't remember the name, but maybe something like BackupSets.xml
FIX (user workaround):
Rename the file BackupSets.xml in the backup destination folder
Re-run Full Backup*
In TFS Admin Console select Scheduled Backups, then click Take Full Backup Now. Or use command line, PowerShell script, API call as desired.
CAUSE: backupsets.xml in backup destination does not contain valid XML.
Why does this cause failure? Backup wizard opens backupsettings.xml then calls XML deserializer function System.Xml.Serialization.XmlSerializer.Deserialize preparing to add new entry. Invalid XML content including empty/zero byte or text-only content will cause deserialize exception.
PRODUCTS IMPACTED: Repro confirmed in TFS2010 and on 2017-11-25 I had repro with TFS2015 SP3 :-O
Fix is fairly straightforward... once you understand what is going on. -Zephan
MICROSOFT CODE BUGFIX/feature improvement request:
BACKUP Wizard exception handling for backupsets.xml deserialize or parsing exceptions.
If XML deserialization error then close backupsets.xml, rename it to backupsets-YYMMDD-hhmm-corrupt-backup.xml, then jump to backupsets.xml file not found functionality.
SEVERITY: HIGH (data loss)
This is a long-standing problem that can lead to major data loss. I've personally seen over 1 month of data loss due to this issue silently blocking backups and making all earlier restore sets unusable (since parsing BackupSets.xml is VERY finicky I couldn't even hack to restore last successful backup.)
Today airbrake reported an exception. Its summary said that the problem occures when sidekiq tries retry the job after a failure. Here's what summary params look like:
{
"retry"=>"true",
"queue"=>"default",
"class"=>"AdwordsReportWorker",
"args"=>"[\"2\", \"2012-11-13\"]",
"jid"=>"51d568e46c412adc327153c8",
"error_message"=>"wrong number of arguments(1 for 0)",
"error_class"=>"ArgumentError",
"failed_at"=>"2012-11-14 13:56:12 UTC",
"retry_count"=>"0",
"controller"=>"",
"action"=>""
}
I seems that the exception is only taking palce when the job fails and retries. I would like to debug this, but I can't get my head around where to start :-(
My questions are:
Under what conditions worker understands it failed finishing the job (from which he descides to retry)? How do I force the worker to fail in attempt to, say, reproduce the problem?
Is there a good tutorial on debugging/examples sidekiq workers?
I am using sidekiq 2.3.3. Will upgrading to newer version solve the problem?
Bonus track.
The actual stacktrace unexpectedly ends up in
[GEM_ROOT]/gems/activerecord-3.2.8/lib/active_record/associations/association.rb:98:in `initialize'
I couldn't find how do debug sidekiq, but apperently the problem I am referring to is a known bug in Rails.
Here are a few lines:
https://github.com/mperham/sidekiq/issues/601
https://github.com/rails/rails/issues/7770