|
View:
New views
3 Messages
—
Rating Filter:
Alert me
|
|
|
Big problem with Sandesha2 Storage API implementation of wso2sandesha2-core-2.1.jarI 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@... http://wso2.org/cgi-bin/mailman/listinfo/commons-user |
|
|
Re: Big problem with Sandesha2 Storage API implementation of wso2sandesha2-core-2.1.jarHi 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@... > http://wso2.org/cgi-bin/mailman/listinfo/commons-user _______________________________________________ Commons-user mailing list Commons-user@... http://wso2.org/cgi-bin/mailman/listinfo/commons-user |
|
|
Re: Big problem with Sandesha2 Storage API implementation of wso2sandesha2-core-2.1.jarI am encountering this same issue while trying to get persistent reliable messaging working. Do you know the status of fixing this bug?
|
| Free Forum Powered by Nabble | Forum Help |