Big problem with Sandesha2 Storage API implementation of wso2sandesha2-core-2.1.jar

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Big problem with Sandesha2 Storage API implementation of wso2sandesha2-core-2.1.jar

Maik Mrazovic

I tried to use WSO2 implementation of Sandesha2 Storage API, as part of WSO2 Server 2.1 (wso2sandesha2-core-2.1.jar):

At class PersistentRMSBeanMgr, method

"public List find(RMSBean bean) throws SandeshaStorageException."

The SQL SELECT with hibernate is done through

      RMSBean rmsExampleBean = bean;

 

      Example example = Example.create(rmsExampleBean).excludeNone().excludeZeroes();

      List list = session.createCriteria(RMSBean.class).add(example).list();

 

This code causes Sandesha2 to SELECT the Database infinitely, cause (e.g.) RMS FLAG of given bean is 1048576, but in database the row has the value 0 (column C_RMS_FLAGS).

So, there will never be filled list of RMS beans! In hibernate SQL log you´ll find hundreds of

"select this_.c_create_seq_msg_id as c1_0_0_, this_.c_sequence_id as c2_0_0_, this_.c_to_epr as c3_0_0_, this_.c_reply_to_epr as c4_0_0_, this_.c_acks_to_epr as c5_0_0_, this_.c_rm_version as c6_0_0_, this_.c_security_token_data as c7_0_0_, this_.c_last_activated_time as c8_0_0_, this_.c_closed as c9_0_0_, this_.c_terminated as c10_0_0_, this_.c_polling_mode as c11_0_0_, this_.c_service_name as c12_0_0_, this_.c_flags as c13_0_0_, this_.c_id as c14_0_0_, this_.c_internal_sequence_id as c15_0_0_, this_.c_create_sequence_msg_store_key as c16_0_0_, this_.c_reference_msg_store_key as c17_0_0_, this_.c_last_send_error as c18_0_0_, this_.c_highest_out_relates_to as c19_0_0_, this_.c_client_completed_messages as c20_0_0_, this_.c_transport_to as c21_0_0_, this_.c_offered_endpoint as c22_0_0_, this_.c_offered_sequence as c23_0_0_, this_.c_anonymous_uuid as c24_0_0_, this_.c_last_send_error_timestamp as c25_0_0_, this_.c_last_out_message as c26_0_0_, this_.c_highest_out_message_number as c27_0_0_, this_.c_next_message_number as c28_0_0_, this_.c_terminate_added as c29_0_0_, this_.c_timed_out as c30_0_0_, this_.c_sequence_closed_client as c31_0_0_, this_.c_expected_replies as c32_0_0_, this_.c_soap_version as c33_0_0_, this_.c_termination_pauser_for_cs as c34_0_0_, this_.c_avoid_auto_termination as c35_0_0_, this_.c_rms_flags as c36_0_0_ from rms_t this_ where (this_.c_closed=? and this_.c_terminated=? and this_.c_polling_mode=? and this_.c_flags=? and this_.c_last_send_error_timestamp=? and this_.c_next_message_number=? and this_.c_terminate_added=? and this_.c_timed_out=? and this_.c_sequence_closed_client=? and this_.c_termination_pauser_for_cs=? and this_.c_avoid_auto_termination=? and this_.c_rms_flags=?)"

Because it searchs and searchs and searchs. Finally the process ends with an

"org.apache.axis2.AxisFault: Time out while waiting for the server to send the response."

 

I run against the derby databse. The same client code of my testcase with the INMEMORY implementation instead works fine. So, in my opinion wso2sandesha2-core-2.1.jar can´t work.

I look forward to your answer.
 
Thanks a lot,
 
Maik

_______________________________________________
Commons-user mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/commons-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Big problem with Sandesha2 Storage API implementation of wso2sandesha2-core-2.1.jar

Afkham Azeez-2
Hi Maik,
Thanks for finding this tricky bug and pointing it out. We will
investigate further & incorporate the fix for this in the next WSAS release.

Thanks
Azeez

Maik Mrazovic wrote:

>   I tried to use WSO2 implementation of Sandesha2 Storage API, as part
> of WSO2 Server 2.1 (wso2sandesha2-core-2.1.jar):
>
> At class PersistentRMSBeanMgr, method * *
>
> * "public * List find(RMSBean bean) * throws * SandeshaStorageException."
>
> The SQL SELECT with hibernate is done through
>
>       RMSBean rmsExampleBean = bean;
>
>  
>
>       Example example =
> Example./create/(rmsExampleBean).excludeNone().excludeZeroes();
>
>       List list = session.createCriteria(RMSBean. * class *
> ).add(example).list();
>
>  
>
> This code causes Sandesha2 to SELECT the Database infinitely, cause
> (e.g.) RMS FLAG of given bean is 1048576, but in database the row has
> the value 0 (column C_RMS_FLAGS).
>
> So, there will never be filled list of RMS beans! In hibernate SQL log
> you´ll find hundreds of
>
> "select this_.c_create_seq_msg_id as c1_0_0_, this_.c_sequence_id as
> c2_0_0_, this_.c_to_epr as c3_0_0_, this_.c_reply_to_epr as c4_0_0_,
> this_.c_acks_to_epr as c5_0_0_, this_.c_rm_version as c6_0_0_,
> this_.c_security_token_data as c7_0_0_, this_.c_last_activated_time as
> c8_0_0_, this_.c_closed as c9_0_0_, this_.c_terminated as c10_0_0_,
> this_.c_polling_mode as c11_0_0_, this_.c_service_name as c12_0_0_,
> this_.c_flags as c13_0_0_, this_.c_id as c14_0_0_,
> this_.c_internal_sequence_id as c15_0_0_,
> this_.c_create_sequence_msg_store_key as c16_0_0_,
> this_.c_reference_msg_store_key as c17_0_0_, this_.c_last_send_error as
> c18_0_0_, this_.c_highest_out_relates_to as c19_0_0_,
> this_.c_client_completed_messages as c20_0_0_, this_.c_transport_to as
> c21_0_0_, this_.c_offered_endpoint as c22_0_0_, this_.c_offered_sequence
> as c23_0_0_, this_.c_anonymous_uuid as c24_0_0_,
> this_.c_last_send_error_timestamp as c25_0_0_, this_.c_last_out_message
> as c26_0_0_, this_.c_highest_out_message_number as c27_0_0_,
> this_.c_next_message_number as c28_0_0_, this_.c_terminate_added as
> c29_0_0_, this_.c_timed_out as c30_0_0_, this_.c_sequence_closed_client
> as c31_0_0_, this_.c_expected_replies as c32_0_0_, this_.c_soap_version
> as c33_0_0_, this_.c_termination_pauser_for_cs as c34_0_0_,
> this_.c_avoid_auto_termination as c35_0_0_, this_.c_rms_flags as
> c36_0_0_ from rms_t this_ where (this_.c_closed=? and
> this_.c_terminated=? and this_.c_polling_mode=? and this_.c_flags=? and
> this_.c_last_send_error_timestamp=? and this_.c_next_message_number=?
> and this_.c_terminate_added=? and this_.c_timed_out=? and
> this_.c_sequence_closed_client=? and this_.c_termination_pauser_for_cs=?
> and this_.c_avoid_auto_termination=? and this_.c_rms_flags=?)"
>
> Because it searchs and searchs and searchs. Finally the process ends
> with an
>
> "org.apache.axis2.AxisFault: Time out while waiting for the server to
> send the response."
>
>  
>
> I run against the derby databse. The same client code of my testcase
> with the INMEMORY implementation instead works fine. So, in my opinion
> wso2sandesha2-core-2.1.jar can´t work.
>
> I look forward to your answer.
>  
> Thanks a lot,
>  
> Maik
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Commons-user mailing list
> [hidden email]
> http://wso2.org/cgi-bin/mailman/listinfo/commons-user



_______________________________________________
Commons-user mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/commons-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Big problem with Sandesha2 Storage API implementation of wso2sandesha2-core-2.1.jar

blaisg
I am encountering this same issue while trying to get persistent reliable messaging working.  Do you know the status of fixing this bug?
Afkham Azeez-2 wrote
Hi Maik,
Thanks for finding this tricky bug and pointing it out. We will
investigate further & incorporate the fix for this in the next WSAS release.

Thanks
Azeez

Maik Mrazovic wrote:
>   I tried to use WSO2 implementation of Sandesha2 Storage API, as part
> of WSO2 Server 2.1 (wso2sandesha2-core-2.1.jar):
>
> At class PersistentRMSBeanMgr, method * *
>
> * "public * List find(RMSBean bean) * throws * SandeshaStorageException."
>
> The SQL SELECT with hibernate is done through
>
>       RMSBean rmsExampleBean = bean;
>
>  
>
>       Example example =
> Example./create/(rmsExampleBean).excludeNone().excludeZeroes();
>
>       List list = session.createCriteria(RMSBean. * class *
> ).add(example).list();
>
>  
>
> This code causes Sandesha2 to SELECT the Database infinitely, cause
> (e.g.) RMS FLAG of given bean is 1048576, but in database the row has
> the value 0 (column C_RMS_FLAGS).
>
> So, there will never be filled list of RMS beans! In hibernate SQL log
> you´ll find hundreds of
>
> "select this_.c_create_seq_msg_id as c1_0_0_, this_.c_sequence_id as
> c2_0_0_, this_.c_to_epr as c3_0_0_, this_.c_reply_to_epr as c4_0_0_,
> this_.c_acks_to_epr as c5_0_0_, this_.c_rm_version as c6_0_0_,
> this_.c_security_token_data as c7_0_0_, this_.c_last_activated_time as
> c8_0_0_, this_.c_closed as c9_0_0_, this_.c_terminated as c10_0_0_,
> this_.c_polling_mode as c11_0_0_, this_.c_service_name as c12_0_0_,
> this_.c_flags as c13_0_0_, this_.c_id as c14_0_0_,
> this_.c_internal_sequence_id as c15_0_0_,
> this_.c_create_sequence_msg_store_key as c16_0_0_,
> this_.c_reference_msg_store_key as c17_0_0_, this_.c_last_send_error as
> c18_0_0_, this_.c_highest_out_relates_to as c19_0_0_,
> this_.c_client_completed_messages as c20_0_0_, this_.c_transport_to as
> c21_0_0_, this_.c_offered_endpoint as c22_0_0_, this_.c_offered_sequence
> as c23_0_0_, this_.c_anonymous_uuid as c24_0_0_,
> this_.c_last_send_error_timestamp as c25_0_0_, this_.c_last_out_message
> as c26_0_0_, this_.c_highest_out_message_number as c27_0_0_,
> this_.c_next_message_number as c28_0_0_, this_.c_terminate_added as
> c29_0_0_, this_.c_timed_out as c30_0_0_, this_.c_sequence_closed_client
> as c31_0_0_, this_.c_expected_replies as c32_0_0_, this_.c_soap_version
> as c33_0_0_, this_.c_termination_pauser_for_cs as c34_0_0_,
> this_.c_avoid_auto_termination as c35_0_0_, this_.c_rms_flags as
> c36_0_0_ from rms_t this_ where (this_.c_closed=? and
> this_.c_terminated=? and this_.c_polling_mode=? and this_.c_flags=? and
> this_.c_last_send_error_timestamp=? and this_.c_next_message_number=?
> and this_.c_terminate_added=? and this_.c_timed_out=? and
> this_.c_sequence_closed_client=? and this_.c_termination_pauser_for_cs=?
> and this_.c_avoid_auto_termination=? and this_.c_rms_flags=?)"
>
> Because it searchs and searchs and searchs. Finally the process ends
> with an
>
> "org.apache.axis2.AxisFault: Time out while waiting for the server to
> send the response."
>
>  
>
> I run against the derby databse. The same client code of my testcase
> with the INMEMORY implementation instead works fine. So, in my opinion
> wso2sandesha2-core-2.1.jar can´t work.
>
> I look forward to your answer.
>  
> Thanks a lot,
>  
> Maik
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Commons-user mailing list
> Commons-user@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/commons-user



_______________________________________________
Commons-user mailing list
Commons-user@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/commons-user
Loading...