I can't tell what's wrong here. Admin and logon message code looks ok, the messages look ok, and data dictionary looks ok.
20211122-12:29:48.018 : Initiated logon request
20211122-12:29:48.129 : Sequence numbers reset due to ResetSeqNumFlag=Y
20211122-12:29:48.129 : Received logon
20211122-12:29:48.129 : Session FIX.4.4:FIX ENGINE.TEST/FIX.API->360T_RFQ_TEST disconnecting: System.NullReferenceException: Object reference not set to an instance of an object.
at IsFixService.IsFixService.OnLogon(SessionID s)
at QuickFix.Session.NextLogon(Message logon)
at QuickFix.Session.Next(MessageBuilder msgBuilder)
at QuickFix.SocketInitiatorThread.ProcessStream()
at QuickFix.SocketInitiatorThread.Read()
The messages are
8=FIX.4.49=11935=A34=149=FIX ENGINE.TEST50=FIX.API52=20211122-12:29:48.01756=360T_RFQ_TEST98=0108=30141=Y554=pwd10=050
8=FIX.4.49=10235=A34=149=360T_RFQ_TEST52=20211122-12:29:48.06556=FIX ENGINE.TEST57=FIX.API98=0108=30141=Y10=160
I am confused why there would be a NextLogon at all because there is only 1 logon.
Ok I was confused between QuickFixN OnLogon override method, and the message cracker OnMessage(QuickFix.FIX44.Logon msg, SessionID s) method.
I thought that the problem was in the OnMessage method which was working fine. The problem was my onLogon method had a NullReferenceException trying to use an uninitalised logon monitoring cache. So my bad.
Related
I am trying to access the attachments for an RDOMail object. When I either search for a specific item using LINQ or just try and iterate through the list with a foreach it freezes outlook and throws no exception.
Also when I try and move the RDOMail to another folder it freezes outlook and throws no exception.
I can accomplish both these things just using the Outlook.MailItem
Anyone have any ideas?
void store_OnNewMail(string entryId)
{
RDOMail mail = _store.GetMessageFromID(entryId);
RDOAttachment protocolAttachment = mail.Attachments.Cast<RDOAttachment>().SingleOrDefault(attach => attach.FileName == "protocol.id");
mail.Move(_hiddenDeliveryTrustFolder);
}
My guess is that the IMAP4 message available at the time of the NewMail event is just an envelope message (header only, no body or attachments). When you access the attachments, IMAP4 provider attempts to connect to the IMAP4 server to retrieve the data, but the call is blocked because of a critical section signaled before the event is raised.
Try to bypass the IMAP4 provider level by
RDOStore unwrappedStore = rSession.Stores.UnwarpStore(_store);
RDOMail mail = unwrappedStore.GetMessageFromID(entryId);
You can also try to save the message entry id in a variable and start a timer (use the one from the Forms namespace). When the timer event fires (you will be out of the newMail event by then), you can open the message and process it.
Is it neccessary to call this line
Session.lookupSession(is).logon();
in this code
socketInitiator.start();
SessionID sessionId = socketInitiator.getSessions().get(0);
Session.lookupSession(id).logon();
while (!Session.lookupSession(id).isLoggedOn()) {
System.out.println("Waiting for login success");
Thread.sleep(500);
}
what is its purpose, as when I omit it, it still gets by the while loop.
EDIT_________________
I was using this in a unit test
socketInitiator.start();
SessionID sessionId = socketInitiator.getSessions().get(0);
Session.lookupSession(id).logon();
while (!Session.lookupSession(id).isLoggedOn()) {
System.out.println("Waiting for login success");
Thread.sleep(500);
}
System.out.println("Logged In...booking SingleOrder from session: " + sessionId);
//check that the party receives the fix message
assertTrue(isBookSingleOrderReceivedFromFixInbound(sessionId));
I have no idea what that function is for, or why it even exists. (I could look it up, sure, but I'm just saying that I've never had to use it.)
The start() call should cause the initiator to start attempting logins (assuming the current time is in the defined session). You shouldn't even have a while loop like this.
You should just call start(), and then do nothing. If logon succeeds, you'll see the FromApp and FromAdmin callbacks start to get triggered for incoming messages (including your logon response).
When failing an authentication strategy in Warden, a message can be passed to the fail! method. How can I access this message in my default failure application action such that I can display it in a flash message? I tried request.env['warden'].message, but after looking at the code for Warden::Proxy this variable is only set for winning strategies. Thoughts?
When using the fail or fail! methods, you can obtain the failure message from the environment warden object.
Example:
def unauthenticated
flash[:alert] = env["warden"].message unless env["warden"].message.blank?
end
http://www.rubydoc.info/github/hassox/warden/Warden/Proxy#message-instance_method
Perhaps a different way of failing strategies (from recent documentation), is to use throw(:warden, :foo => 'bar'). Anything you throw with will be available in your failure application through request.env['warden.options'], including a string of the desired url as well. HTH
I have the following logout action:
public function logoutAction() {
Zend_Auth::getInstance()->clearIdentity();
Zend_Session::destroy();
$this->_helper->flashMessenger->addMessage(array('success' =>
_('You were successfully logged out.')));
$this->_redirect('/index/index');
}
If I don't comment out the line: Zend_Session::destroy() I get an error:
Fatal error: Uncaught exception 'Zend_Session_Exception' with message 'The session was explicitly destroyed during this request, attempting to re-start is not allowed.' in /usr/local/share/php/library/Zend/Controller/Plugin/Broker.php on line 336 Zend_Session_Exception: The session was explicitly destroyed during this request, attempting to re-start is not allowed.
I have read about this issue here and here but remain unclear on how I should proceed. Should I just not use Zend_Session::destroy()? What would be the implications and dangers of not using it, and what is the alternative?
What causes you problems is, that right after destroying the session, you are reusing it (by facilitating the FlashMessenger. If not destroying the session after logout bothers you, you could display a logout page instead of redirecting to your frontpage with a flash message.
Leaving some of your session data intact after your user logged out, might have security implications, but that depends on what you store in your session and where and how you use the data. In order to make sure, that you don't keep data, that belonged to the logged in user in your session, just use a specific session namespace for this data and call unsetNamespace() upon logout.
Zend_Auth have its own session namespace and after Zend_Auth::getInstance()->clearIdentity(); it removes it so there is no need to destroy all session nemaspaces if you use them.
Example what here happens:
// logging user
$_SESSION['Zend_Auth'] = 'logged user data';
// after Zend_Auth::getInstance()->clearIdentity();
$_SESSION['Zend_Auth'] = null;
// after Zend_Session::destroy();
session_destroy();
I've started using the AspProviders code to store my session data in my table storage.
I'm sporadically getting the following error:
Description: Exception of type 'System.Web.HttpException' was thrown. INNER_EXCEPTION:Error accessing the data store! INNER_EXCEPTION:An error occurred while processing this request. INNER_EXCEPTION: ConditionNotMet The condition specified using HTTP conditional header(s) is not met. RequestId:0c4239cc-41fb-42c5-98c5-7e9cc22096af Time:2010-10-15T04:28:07.0726801Z
StackTrace:
System.Web.SessionState.SessionStateModule.EndAcquireState(IAsyncResult ar)
System.Web.HttpApplication.AsyncEventExecutionStep.OnAsyncEventCompletion(IAsyncResult ar) INNER_EXCEPTION:
Microsoft.Samples.ServiceHosting.AspProviders.TableStorageSessionStateProvider.ReleaseItemExclusive(HttpContext context, String id, Object lockId) in \Azure\AspProviders\TableStorageSessionStateProvider.cs:line 484
System.Web.SessionState.SessionStateModule.GetSessionStateItem()
System.Web.SessionState.SessionStateModule.PollLockedSessionCallback(Object state) INNER_EXCEPTION:
Microsoft.WindowsAzure.StorageClient.Tasks.Task1.get_Result()
Microsoft.WindowsAzure.StorageClient.Tasks.Task1.ExecuteAndWait()
Microsoft.WindowsAzure.StorageClient.TaskImplHelper.ExecuteImplWithRetry[T](Func`2 impl, RetryPolicy policy)
Microsoft.Samples.ServiceHosting.AspProviders.TableStorageSessionStateProvider.ReleaseItemExclusive(TableServiceContext svc, SessionRow session, Object lockId) in \Azure\AspProviders\TableStorageSessionStateProvider.cs:line 603
Microsoft.Samples.ServiceHosting.AspProviders.TableStorageSessionStateProvider.ReleaseItemExclusive(HttpContext context, String id, Object lockId) in \Azure\AspProviders\TableStorageSessionStateProvider.cs:line 480 INNER_EXCEPTION:
System.Data.Services.Client.DataServiceContext.SaveResult.d__1e.MoveNext()
Anyone run into this? The only useful information I've found is this, which I'm hesitant to do:
If you want to bypass the validation, you can open TableStorageSessionStateProvider.cs, find ReleaseItemExclusive, and modify the code from:
svc.UpdateObject(session);
to:
svc.Detach(session);
svc.AttachTo("Sessions", session, "*");
svc.UpdateObject(session);
from here
Thanks!
So I decided to change this:
svc.UpdateObject(session);
svc.SaveChangesWithRetries();
to this:
try
{
svc.UpdateObject(session);
svc.SaveChangesWithRetries();
}
catch
{
svc.Detach(session);
svc.AttachTo("Sessions", session, "*");
svc.UpdateObject(session);
svc.SaveChangesWithRetries();
}
So, I'll see how that works...
I've encountered this problem as well and after some investigation it seems to happen more often when you have more than one instance and you try to make calls in rapid succession in the same session. (e.g. if you had an auto complete box and making ajax calls on each key press)
This occurs because when you try to access the session data, first of all the web server takes out a lock on that session. When the request is complete, it releases the lock. With the table service provider, it updates this lock status by updating a field in the table. What I think is happening is that Instance1 loads the session row, then Instance2 loads the session row, Instance1 saves down the updated lock status and when Instance2 attempts to save the lock status it gets an error because the object isn't in the same state as when it loaded it (the ETag doesn't match any more).
This is why the fix that you found will stop the error from occurring, because by specifying the "*" in the AttachTo, when Instance2 attempts to save the lock it will turn off ETag checking (and over write the changes made by Instance1).
In our situation we have altered the provider so that we can turn off session for certain paths (the ajax call that was giving us our problems didn't need access to session data, neither did the loading of images) which may be an option for you depending on what is causing your problem.
Unfortunately the TableStorageSessionStateProvider is part of the sample projects and so isn't (as far as I'm aware, but I'll happily be told otherwise) officially supported by Microsoft. It does have other issues, like the fact that it doesn't clean up it's session data once a session expires, so you will end up with lots of junk in the session table and blob container that you'll have to clean up some other way.